This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix always_inline


On Sat, May 10, 2008 at 4:58 PM, Diego Novillo <dnovillo@google.com> wrote:
> On 5/5/08 4:06 AM, Jan Hubicka wrote:
>
>> I am planning to give SSA at -O0 try.  I guess to get it for real, we
>> will need to be more considerate about debug info in SSA path and we
>> should see how much expenses whole thing have.  Should not TER die with
>> tuples merge?
>
> Not quite yet.  I had hoped to get around to it, but the conversion to
> tuples was very invasive.  Removing TER will have to wait for another
> branch, unfortunately.
>
> One of the current regressions in the branch is very likely codegen lameness
> because we are expanding GIMPLE directly.
>
> SSA at -O0 caused some grief when Manuel tried last year, but I didn't do
> the work, so I don't remember precise details.

ISTR that Honza has it working to some extent already.

There are two immediate benefits I can see

 - we can run a simple CCP pass, only propagating into asms and certain builtin
   function arguments making "inline functions as fast as macros" also work
   reliably at -O0 (with always_inline of course).

 - some flow sensitive warnings can be enabled

 (- we can run dce reducing the size of -O0 executables)

the last one needs to be evaluated in how it will affect debug information, but
with no propagations it shouldn't make a visible difference.

And of course reducing the number of different paths through the compiler is
worth it on its own IMHO.

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]