<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:tejohnson@google.com" title="Teresa Johnson <tejohnson@google.com>"> <span class="fn">Teresa Johnson</span></a>
</span> changed
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - clang -flto doesn't respect -fno-unroll-loops option"
href="https://bugs.llvm.org/show_bug.cgi?id=35139">bug 35139</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>NEW
</td>
<td>RESOLVED
</td>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>---
</td>
<td>FIXED
</td>
</tr>
<tr>
<td style="text-align:right;">CC</td>
<td>
</td>
<td>florian_hahn@apple.com
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - clang -flto doesn't respect -fno-unroll-loops option"
href="https://bugs.llvm.org/show_bug.cgi?id=35139#c4">Comment # 4</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - clang -flto doesn't respect -fno-unroll-loops option"
href="https://bugs.llvm.org/show_bug.cgi?id=35139">bug 35139</a>
from <span class="vcard"><a class="email" href="mailto:tejohnson@google.com" title="Teresa Johnson <tejohnson@google.com>"> <span class="fn">Teresa Johnson</span></a>
</span></b>
<pre>(In reply to Takahiro Kawashima from <a href="show_bug.cgi?id=35139#c3">comment #3</a>)
<span class="quote">> 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</span >
Ideally with LTO this should behave the same as without LTO. Without LTO the
-fno-vectorize on the link would not have any effect.
<span class="quote">>
> 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?</span >
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.
<span class="quote">>
> 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.</span >
-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.
<span class="quote">>
> Of course, if attributes are set to the loop/function/module
> (via pragma or something), they should be applied.
>
> Any thoughts?</span ></pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>