* 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).