[llvm-commits] [llvm-gcc-4.2] r51608 - /llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp

[Evan Cheng]

On May 28, 2008, at 11:30 AM, Duncan Sands wrote:

> Hi Evan,
>
>>> To get the same effect as gcc in a way that works for all languages,
>>> I think we need to run the inliner if flag_inline_trees != 0 and add
>>> all functions with !DECL_INLINE to llvm.noinline.  Or would that be
>>> too expensive?
>>
>> That doesn't seem like the right solution to me. llvm language  
>> doesn't
>> have the "inline" keyword. Can we just say llvm ignore the inline  
>> hint?
>>
>>>> Perhaps it would be simpler to check for flag_inline_functions
>>>> instead
>>>> in llvm-backend.cpp?
>>>
>>> It would be simpler, but it would only work the same way as gcc for
>>> the C like languages, and not for Ada or Fortran.
>>
>> Is it possible to fix the Ada and Fortran frontend to match the C
>> frontend?
>
> Or fix the C front-end to match one of the others :)  By the way, just
> looking at flag_inline_trees > 1 means you don't inline functions  
> marked
> "inline" at -O2.

There is no guarantee we inline "inline" functions even if we run the  
inliner. llvm does not yet have a way to represent the "inline"  
keyword, right?

>
>
> Why don't we just run the inliner at -O2 with some kind of threshold
> that shouldn't increase size and be happy with that?  Is there  
> anything
> wrong with inlining at -O2?  If people don't want certain functions  
> to be
> inlined then they can mark them noinline.

We are running the inliner at -O2, no? We are no longer checking the  
optimizer level. The issue here is llvm-gcc still run the inliner even  
with -fno-inline-function.

Can we rely on the gcc inliner to handle functions that are marked  
inline until we add the inline hint to llvm? Could that be the reason  
why WebKit regressed when the gcc inliner is disabled completely?

Evan

>
>
> Ciao,
>
> Duncan.