[PATCH] gcc compatibility: silent -finline-limit=1234 & -finline-limit

[Alp Toker]

On 05/07/2014 00:55, Arthur Marble wrote:
>
> Hello,
>
> That makes more sense to me sorry for the confusion. How should I go 
> about implementing this?
>

1) Find out the exact semantics of the GCC flag.

2) Pinpoint the spot in the LLVM backend where that inlining decision is 
made, asking the llvmdev list for advice with a summary of (1).

3) Add the necessary check at that point in LLVM to disable inlining if 
the size is greater than the flag value.

3) Adapt the clang frontend to pass through the flag as a codegen 
option, or perhaps just pass it through from the driver as a -mllvm 
option. Whichever makes more sense.

I *suspect* the whole feature can be implemented in a dozen or so LoC, 
which is why I suggested it's worth doing.

The caveat: If it's a lot more work than that, it's probably not worth 
the effort to develop or maintain. I'm hopeful it's a simple one though.

Alp.



> Regards,
> Arthur
>
> On Jul 4, 2014 11:52 PM, "Alp Toker" <alp at nuanti.com 
> <mailto:alp at nuanti.com>> wrote:
>
>
>     On 05/07/2014 00:44, Arthur Marble wrote:
>
>         Hello,
>
>         That makes sense to me for other flags but in this case isn't
>         clang not planning to support inline functions? If it is not
>         then should we have the compiler spit out a message about how
>         this is not used?
>
>
>     Hi Arthur,
>
>     I believe the -finline-limit= warning is related to inliner
>     decisions in the code generator backend, not the GNU nested
>     function language extension.
>
>     Alp.
>
>
>         Regards,
>         Arthur
>
>
>         On Fri, Jul 4, 2014 at 3:11 PM, Alp Toker <alp at nuanti.com
>         <mailto:alp at nuanti.com> <mailto:alp at nuanti.com
>         <mailto:alp at nuanti.com>>> wrote:
>
>             Patch?
>
>             I investigated this flag too a while back and reached the
>             conclusion it's only interesting to support if we actually
>         hook it
>             into the backend.
>
>             Otherwise it's unfair to users to silently claim support
>         for an
>             option that has semantic significance, only to go and
>         ignore it.
>             Especially if it's only to unblock a dozen packages it'd
>         be a shame.
>
>             On the plus side, it was really rewarding to implement a
>             GCC-compatible -Wframe-larger-than= a few weeks ago so I *do*
>             think there's value in providing real implementations of these
>             flags because it informs decisions we need to make about
>             backend/frontend layering.
>
>             Alp.
>
>
>             On 04/07/2014 18:15, Rafael Ávila de Espíndola wrote:
>
>                 adding cfe-commits
>
>         http://reviews.llvm.org/D4376
>
>
>
>                 _______________________________________________
>                 cfe-commits mailing list
>         cfe-commits at cs.uiuc.edu <mailto:cfe-commits at cs.uiuc.edu>
>         <mailto:cfe-commits at cs.uiuc.edu <mailto:cfe-commits at cs.uiuc.edu>>
>         http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
>             -- http://www.nuanti.com
>             the browser experts
>
>
>
>     -- 
>     http://www.nuanti.com
>     the browser experts
>

-- 
http://www.nuanti.com
the browser experts