------- Additional Comments From pinskia at physics dot uc dot edu 2005-05-16 20:34 ------- Subject: Re: [4.0/4.1 Regression] ICE in make_decl_rtl
On May 16, 2005, at 4:28 PM, joseph at codesourcery dot com wrote: >> ------- Additional Comments From pinskia at gcc dot gnu dot org >> 2005-05-16 20:03 ------- >> (In reply to comment #3) >>> If you get rid of decl_constant_value_for_broken_optimization then I >>> suspect you'll lose some optimizations because fold doesn't operate >>> on SSA >>> so some constant values won't be available to fold, only to later >>> optimizations. But you'll get rid of the only references to >>> "optimize" in >>> the C front end other than those defining built-in macros, and the >>> front-end shouldn't care about "optimize" in principle, and you'll >>> probably get rid of some XFAILs in c9?-const-expr-?.c in the process. >> >> Why do you believe fold does not operate on SSA? > > Fold has optimizations working on large complicated trees of > expressions, > looking at their subexpressions and subsubexpressions; such trees are > only > available during parsing, before conversion to GIMPLE form. If the > constants aren't available in these non-GIMPLE trees then you lose the > optimizations. The folding called from the SSA optimizers can only > fold > smaller fragments of trees. Everything fold does which looks at > subexpressions and subsubexpressions of non-GIMPLE trees can in > principle > be done on GIMPLE but I don't think there's evidence that every such > fold > optimization is implemented for GIMPLE. Yes that is what the tree combiner would do but since I have not have time to work it, we are missing more and more optimizations because not having it. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21610
