r192521 - Add missing flags -fexpensive-optimizations and -minline-all-stringops as noops.

[Alp Toker]

On 15/10/2013 22:27, Richard Smith wrote:
> On Tue, Oct 15, 2013 at 2:07 PM, Chandler Carruth
> <chandlerc at google.com <mailto:chandlerc at google.com>> wrote:
>
>
>     On Tue, Oct 15, 2013 at 1:53 PM, Joerg Sonnenberger
>     <joerg at britannica.bec.de <mailto:joerg at britannica.bec.de>> wrote:
>
>         On Mon, Oct 14, 2013 at 04:58:55PM -0700, Chandler Carruth wrote:
>         > Whether it is correct or not, people were not using
>         -minline-all-stringops
>         > to avoid calling out to libc for them, they were using it as
>         equivalent to
>         > -O9 or whatever. =/ By ignoring this flag we correctly
>         compile a nontrivial
>         > amount of code out there.
>
>         My gut instinct tells me that it might be the path of least
>         resistence
>         to silently accept -fexpensive-optimisations, but that it
>         doesn't make
>         sense to give -minline-all-stringops the same threatment. I am
>         going to
>         run some field study now to verify the intuition. I can
>         already say that
>         there are a number of wtf moments ahead...
>
>
>     For the record, we ran plenty of field experiments ourselves. We
>     have had no problems with this.
>
>     And in fact, I'm moderately confident we wont run into any *new*
>     ones because as Nick pointed out ages ago in this thread, Clang
>     used to ignore this flag, and every clang release has ignored this
>     flag! We have never released a Clang compiler which rejected this
>     flag.
>
>
> Right. Instead of thinking about this change making us silently accept
> -minline-all-stringops, let's think about this change plus r191328
> adding diagnostics for all *other* unknown -m options. I don't think
> anyone is claiming that in the long term we should keep silently
> ignoring -minline-all-stringops, but r191328 introduces a regression
> without this patch, reverting r191328 is worse than keeping this
> change, and there aren't really any other options on the table for the
> immediate future.

Both sides of the argument are convincing and seemingly intractable, but
maybe there's a third way -- how about implementing the feature in LLVM?

Here's a pure guess, not tested but whatever the implementation ends up
being it'll surely take less time than continuing the debate:

diff --git a/lib/Transforms/IPO/FunctionAttrs.cpp b/lib/Transforms/IPO/FunctionAttrs.cpp

index 386cb71..69f6de9 100644

--- a/lib/Transforms/IPO/FunctionAttrs.cpp

+++ b/lib/Transforms/IPO/FunctionAttrs.cpp

@@ -820,6 +820,18 @@ bool FunctionAttrs::inferPrototypeAttributes(Function &F) {

   if (!(TLI->getLibFunc(F.getName(), TheLibFunc) && TLI->has(TheLibFunc)))

     return false;

 

+  if (getenv("inline_all_stringops"))

+  if (!F.hasFnAttribute(Attribute::AlwaysInline)) {

+    F.addFnAttr(Attribute::AlwaysInline);

+    ++NumAnnotated;

+  }

+

+  if (getenv("no_inline_all_stringops"))

+  if (!F.hasFnAttribute(Attribute::NoInline)) {

+    F.addFnAttr(Attribute::NoInline);

+    ++NumAnnotated;

+  }

+

   switch (TheLibFunc) {

   case LibFunc::strlen:

     if (FTy->getNumParams() != 1 || !FTy->getParamType(0)->isPointerTy())






>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

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