* A question about integer promotion in GCC
@ 2004-09-02 7:56 Jie Zhang
2004-09-02 8:09 ` Jie Zhang
2004-09-02 8:19 ` Joseph S. Myers
0 siblings, 2 replies; 10+ messages in thread
From: Jie Zhang @ 2004-09-02 7:56 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: A question about integer promotion in GCC
2004-09-02 7:56 A question about integer promotion in GCC Jie Zhang
@ 2004-09-02 8:09 ` Jie Zhang
2004-09-02 8:19 ` Joseph S. Myers
1 sibling, 0 replies; 10+ messages in thread
From: Jie Zhang @ 2004-09-02 8:09 UTC (permalink / raw)
To: gcc
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: A question about integer promotion in GCC
2004-09-02 7:56 A question about integer promotion in GCC Jie Zhang
2004-09-02 8:09 ` Jie Zhang
@ 2004-09-02 8:19 ` Joseph S. Myers
2004-09-03 8:33 ` Jie Zhang
2004-09-06 8:01 ` Nathan Sidwell
1 sibling, 2 replies; 10+ messages in thread
From: Joseph S. Myers @ 2004-09-02 8:19 UTC (permalink / raw)
To: Jie Zhang; +Cc: gcc
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)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: A question about integer promotion in GCC
2004-09-02 8:19 ` Joseph S. Myers
@ 2004-09-03 8:33 ` Jie Zhang
2004-09-06 8:01 ` Nathan Sidwell
1 sibling, 0 replies; 10+ messages in thread
From: Jie Zhang @ 2004-09-03 8:33 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: gcc
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: A question about integer promotion in GCC
2004-09-02 8:19 ` Joseph S. Myers
2004-09-03 8:33 ` Jie Zhang
@ 2004-09-06 8:01 ` Nathan Sidwell
2004-09-06 8:43 ` Joseph S. Myers
1 sibling, 1 reply; 10+ messages in thread
From: Nathan Sidwell @ 2004-09-06 8:01 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: Jie Zhang, gcc
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: A question about integer promotion in GCC
2004-09-06 8:01 ` Nathan Sidwell
@ 2004-09-06 8:43 ` Joseph S. Myers
2004-09-06 8:52 ` Nathan Sidwell
0 siblings, 1 reply; 10+ messages in thread
From: Joseph S. Myers @ 2004-09-06 8:43 UTC (permalink / raw)
To: Nathan Sidwell; +Cc: Jie Zhang, gcc
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)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: A question about integer promotion in GCC
2004-09-06 8:43 ` Joseph S. Myers
@ 2004-09-06 8:52 ` Nathan Sidwell
2004-09-06 9:01 ` Joseph S. Myers
0 siblings, 1 reply; 10+ messages in thread
From: Nathan Sidwell @ 2004-09-06 8:52 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: Jie Zhang, gcc
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: A question about integer promotion in GCC
2004-09-06 8:52 ` Nathan Sidwell
@ 2004-09-06 9:01 ` Joseph S. Myers
2004-09-06 9:54 ` Nathan Sidwell
0 siblings, 1 reply; 10+ messages in thread
From: Joseph S. Myers @ 2004-09-06 9:01 UTC (permalink / raw)
To: Nathan Sidwell; +Cc: Jie Zhang, gcc
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)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: A question about integer promotion in GCC
2004-09-06 9:01 ` Joseph S. Myers
@ 2004-09-06 9:54 ` Nathan Sidwell
2004-09-06 11:59 ` Joseph S. Myers
0 siblings, 1 reply; 10+ messages in thread
From: Nathan Sidwell @ 2004-09-06 9:54 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: Jie Zhang, gcc
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: A question about integer promotion in GCC
2004-09-06 9:54 ` Nathan Sidwell
@ 2004-09-06 11:59 ` Joseph S. Myers
0 siblings, 0 replies; 10+ messages in thread
From: Joseph S. Myers @ 2004-09-06 11:59 UTC (permalink / raw)
To: Nathan Sidwell; +Cc: Jie Zhang, gcc
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)
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2004-09-06 11:59 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-02 7:56 A question about integer promotion in GCC Jie Zhang
2004-09-02 8:09 ` Jie Zhang
2004-09-02 8:19 ` Joseph S. Myers
2004-09-03 8:33 ` Jie Zhang
2004-09-06 8:01 ` Nathan Sidwell
2004-09-06 8:43 ` Joseph S. Myers
2004-09-06 8:52 ` Nathan Sidwell
2004-09-06 9:01 ` Joseph S. Myers
2004-09-06 9:54 ` Nathan Sidwell
2004-09-06 11:59 ` Joseph S. Myers
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).