[llvm-bugs] [Bug 35139] clang -flto doesn't respect -fno-unroll-loops option

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=35139

Teresa Johnson <tejohnson at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
                 CC|                            |florian_hahn at apple.com

--- Comment #4 from Teresa Johnson <tejohnson at google.com> ---
(In reply to Takahiro Kawashima from comment #3)
> I have the same problem with -fno-vectorize.
> 
> I've roughly understood the current implementation.
> 
> Consider the following example (-f options are selected randomly).
> 
> > clang -flto -O1 -ffast-math -c foo.c -o foo.o
> > clang -flto -O2 -fno-unroll-loops -c bar.c -o bar.o
> > clang -flto -O3 -fno-vectorize foo.o bar.o -o main

Ideally with LTO this should behave the same as without LTO. Without LTO the
-fno-vectorize on the link would not have any effect.

> 
> In this case, optimization is done as follow.
> 
> - foo.o is optimized with `-O1 -ffast-math`
> - bar.o is optimized with `-O2 -fno-unroll-loops`
> - main is re-optimized with `-O3`
> 
> Optimization options specified at the compile-time and optimization
> options at the link-time other than -On (and some others?) are ignored
> at the link-time. Right?

There are a few that are converted by the clang driver into corresponding
linker options, but we are trying to change to an approach of passing all
necessary info through the IR instead. It's not a scalable approach to
intercept all possible options this way, and as I mentioned above, requires
changes to where options are passed from non-LTO builds, which is less than
optimal. The other issue is that it doesn't allow for different options passed
to different TUs as in a non-LTO compile.

> 
> From a user point of view, optimization options at the link-time
> other than -On (-fno-vectorize in the case above) should be
> effective at the link-time, because -On is effective.

-On is one of the options passed through by the driver, but that is not the
ideal approach going forward for most -f options, for the reasons mentioned
above.

Note that this particular bug with -fno-unroll-loops handling should now be
fixed as of this morning by rG338be9c59527.

The -fno-vectorize LTO issue is tracked by PR45434.

> 
> Of course, if attributes are set to the loop/function/module
> (via pragma or something), they should be applied.
> 
> Any thoughts?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200407/fd20d222/attachment.html>