A question about integer promotion in GCC

A question about integer promotion in GCC

[Jie Zhang]

For this simple case:

   int
   foo (unsigned short x)
   {
     return (x << 8) | (x >> 8);
   }

its t03.original dump is:

   ;; Function foo (foo)
   ;; enabled by -tree-original


   {
     return (int)x << 8 | (int)(x >> 8);
   }

My question is why GCC treat two bitwise shift operators differently. 
C99 reads:

   (6.5.7.3) The integer promotions are performed on each of the
   operands. The type of the result is that of the promoted left
   operand. [snip]

According to this, shouldn't it be:

     return (int)x << 8 | (int)x >> 8;

Maybe it has no performance benefit. But it make the tree dump result 
conforming to the standard and improve the readability of the final 
assembly output when being compiled using -O2 option. How about your 
thoughts?


regards
-- 
Jie

Re: A question about integer promotion in GCC

[Jie Zhang]

 > Maybe it has no performance benefit. But it make the tree dump result
 > conforming to the standard and improve the readability of the final
 > assembly output when being compiled using -O2 option. How about your
                                             ~~~Here should be -O0.
 > thoughts?

Sorry for inconvenience.

regards.
-- 
Jie

Re: A question about integer promotion in GCC

[Joseph S. Myers]

On Thu, 2 Sep 2004, Jie Zhang wrote:

> According to this, shouldn't it be:
> 
>     return (int)x << 8 | (int)x >> 8;
> 
> Maybe it has no performance benefit. But it make the tree dump result
> conforming to the standard and improve the readability of the final assembly
> output when being compiled using -O2 option. How about your thoughts?

The current function of tree dumps is for debugging the compiler, not as a 
representation of source.  Various optimisations are performed on the 
trees generated, both in the process of generating them to avoid 
generating unnecessary garbage, and as part of fold(), before they get to 
the first tree dumps.  (In this case, a right shift of a short can be 
represented directly on the short, whereas a left shift of a short 
cannot.)

There is a mood towards doing less such optimisations at parse time (and 
generally reducing the front end / middle end overlap), in particular 
reducing parse-time folding to constant folding only and causing the 
remaining optimisations fold() does to be done later on GIMPLE.  This is 
however a substantial task to do while being sure that each change is an 
incremental improvement that does not cause regressions, as every useful 
transformation fold() does would need implementing at a later stage, and 
the result would need careful checking to be sure that all such 
transformations had been properly implemented, before any can be removed 
from fold().

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: A question about integer promotion in GCC

[Jie Zhang]

Joseph S. Myers wrote:
> On Thu, 2 Sep 2004, Jie Zhang wrote:
>>According to this, shouldn't it be:
>>
>>    return (int)x << 8 | (int)x >> 8;
>>
> 
> The current function of tree dumps is for debugging the compiler, not as a 
> representation of source.  Various optimisations are performed on the 
> trees generated, both in the process of generating them to avoid 
> generating unnecessary garbage, and as part of fold(), before they get to 
> the first tree dumps.  (In this case, a right shift of a short can be 
> represented directly on the short, whereas a left shift of a short 
> cannot.)
> 

I think optimizing "(int)x >> 8" to "(int)(x >> 8)" is not good, at least for RISCs, like MIPS. Now gcc (3.4.0) generates the following assembly with option -O0:

  lhu     $2,0($fp)
  sll     $2,$2,8
  lhu     $3,0($fp)
  srl     $3,$3,8
  andi    $3,$3,0xffff
  or      $2,$2,$3

IMO, the "andi" instruction is useless. I suspect it's due to this optimization. Without knowing it this assembly is confusing.

> There is a mood towards doing less such optimisations at parse time (and 

I like this idea. It will make both the structure of GCC and the -O0 assembly output more clear.


regards
-- 
Jie

Re: A question about integer promotion in GCC

[Nathan Sidwell]

Joseph S. Myers wrote:

> There is a mood towards doing less such optimisations at parse time (and 
> generally reducing the front end / middle end overlap), in particular 
> reducing parse-time folding to constant folding only and causing the 
> remaining optimisations fold() does to be done later on GIMPLE.  This is 
> however a substantial task to do while being sure that each change is an 
> incremental improvement that does not cause regressions, as every useful 
> transformation fold() does would need implementing at a later stage, and 
> the result would need careful checking to be sure that all such 
> transformations had been properly implemented, before any can be removed 
> from fold().

IMO when to tackle this is after the next release branches, and the
way to do is implement fe-fold-constant-expr (tree, flags) first, and then
make a fold-const optimizer pass from the remnants.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: A question about integer promotion in GCC

[Joseph S. Myers]

On Mon, 6 Sep 2004, Nathan Sidwell wrote:

> IMO when to tackle this is after the next release branches, and the
> way to do is implement fe-fold-constant-expr (tree, flags) first, and then
> make a fold-const optimizer pass from the remnants.

That seems a plausible approach.  (With the interface for folding true 
constants then getting adapted so it can pass overflow information back 
other than by TREE_OVERFLOW etc., with a view to removing those overflow 
flags from constants.)  Splitting fold that way, with the subsequent pass 
running just before gimplification, should be straightforward.  (I don't 
know what performance impact there might be, though gains from smaller 
footprint while parsing the whole file before optimising any of it are 
possible.)  The hard bit would be creating a fold parse for GIMPLE that 
does everything fold currently does.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: A question about integer promotion in GCC

[Nathan Sidwell]

Joseph S. Myers wrote:
> On Mon, 6 Sep 2004, Nathan Sidwell wrote:
> 
> 
>>IMO when to tackle this is after the next release branches, and the
>>way to do is implement fe-fold-constant-expr (tree, flags) first, and then
>>make a fold-const optimizer pass from the remnants.
> 
> 
> That seems a plausible approach.  (With the interface for folding true 
> constants then getting adapted so it can pass overflow information back 
> other than by TREE_OVERFLOW etc., with a view to removing those overflow 
yay!

> flags from constants.)  Splitting fold that way, with the subsequent pass 
> running just before gimplification, should be straightforward.  (I don't 
I'd suspect we don't want it to run once just there.  It should be cheap
enough to run multiple times on gimple form.

> know what performance impact there might be, though gains from smaller 
> footprint while parsing the whole file before optimising any of it are 
> possible.)  The hard bit would be creating a fold parse for GIMPLE that 
> does everything fold currently does.
sure, but that's a goal that can be incrementally acheived.

nathan
-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: A question about integer promotion in GCC

[Joseph S. Myers]

On Mon, 6 Sep 2004, Nathan Sidwell wrote:

> > flags from constants.)  Splitting fold that way, with the subsequent pass
> > running just before gimplification, should be straightforward.  (I don't 
> I'd suspect we don't want it to run once just there.  It should be cheap
> enough to run multiple times on gimple form.
> 
> > know what performance impact there might be, though gains from smaller
> > footprint while parsing the whole file before optimising any of it are
> > possible.)  The hard bit would be creating a fold parse for GIMPLE that does
> > everything fold currently does.
> sure, but that's a goal that can be incrementally acheived.

I agree we want to run it multiple times on GIMPLE.  Putting the existing 
fold just before gimplification is to avoid regressions.  Because folding 
of subexpressions feeds back into optimisations on the full expression, 
things can't be removed from the existing fold without potential for 
regressions until all the optimisations have been implemented to work on 
GIMPLE; just as it's taking a while to eliminate cases some RTL passes get 
which tree-ssa doesn't so that those RTL passes can be removed.  While the 
implementation of everything for GIMPLE is something that can and so must 
be done incrementally, each optimisation placed there improving the 
optimisation of programs that use explicit temporaries rather than 
complicated expressions.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: A question about integer promotion in GCC

[Nathan Sidwell]

Joseph S. Myers wrote:
> I agree we want to run it multiple times on GIMPLE.  Putting the existing 
> fold just before gimplification is to avoid regressions.  Because folding 
> of subexpressions feeds back into optimisations on the full expression, 
> things can't be removed from the existing fold without potential for 
> regressions until all the optimisations have been implemented to work on 
> GIMPLE; just as it's taking a while to eliminate cases some RTL passes get 
> which tree-ssa doesn't so that those RTL passes can be removed.  While the 
> implementation of everything for GIMPLE is something that can and so must 
> be done incrementally, each optimisation placed there improving the 
> optimisation of programs that use explicit temporaries rather than 
> complicated expressions.

Ah, I see we're actually sort of in agreement.  I'd prefer not to see the
stepping-stone pre-gimple stage you propose -- mainly as a driver to force
the other optimizations to be written.  Perhaps the simplest way to do this
is to keep the current fold as a selectable pre-gimple pass during the
transition.  That way we (a) guarantee we can't be regressing, (b) can
turn it on and off at will, thereby determining if the remaining optimizers
are missing stuff, (c) don't have to rewrite it as a temporary pass.

Let's revisit this when the branch actually happens.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: A question about integer promotion in GCC

[Joseph S. Myers]

On Mon, 6 Sep 2004, Nathan Sidwell wrote:

> Ah, I see we're actually sort of in agreement.  I'd prefer not to see the
> stepping-stone pre-gimple stage you propose -- mainly as a driver to force
> the other optimizations to be written.  Perhaps the simplest way to do this

Not doing X in order to force Y to be done, or in the expectation that Y 
will be done and make X unnecessary, tends to lead to regressions.  This 
has happened several times with temporary fixes for particular bugs going 
on a release branch, but not on mainline in the expectation there will be 
a better fix going on mainline later - the better fix sometimes doesn't 
materialise and we're left with a regression to deal with again for the 
next release.  So I prefer just keeping mainline regression-free, even if 
that means that sometimes there is something temporary there we want to 
supersede.

Exactly how fold is kept in operation until all its optimisations are 
implemented on GIMPLE is something I don't think matters that much.

Determining which bits of folding should be done at -O0 (at present most 
but not all of it is) to get the quickest compile times will need 
experimentation once it is operating on GIMPLE.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)