<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 22, 2017 at 11:11 AM Davide Italiano <<a href="mailto:davide@freebsd.org">davide@freebsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Jun 22, 2017 at 11:03 AM, David Blaikie via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
><br>
> On Thu, Jun 22, 2017 at 10:45 AM Joerg Sonnenberger via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> On Thu, Jun 22, 2017 at 05:35:51PM +0000, David Blaikie wrote:<br>
>> > optnone should work, but really noinline should probably (Chandler: Can<br>
>> > you<br>
>> > confirm: is it reasonable to model noinline as "no interprocedural<br>
>> > analysis<br>
>> > across this function boundary" (so FunctionAttrs should do the same<br>
>> > thing<br>
>> > for noinline as it does for optnone, for example? ie: not derive any new<br>
>> > attributes) - allowing the function to be optimized internally (unlike<br>
>> > optnone) but not allowing interprocedural analysis inside the function<br>
>> > to<br>
>> > be used in callers (unlike optnone)) work as well?<br>
>><br>
>> I don't think it is reasonable to expect "noinline" to mean "must not do<br>
>> IPA". There are different reasons for using "noinline": ensuring a stack<br>
>> frame, forcing outlining of "cold" code etc. Many of those reasons are<br>
>> perfectly fine to still allow IPA. Debug hooks fall into two categories:<br>
>> making sure that the call happens (noinline should allow that)<br>
><br>
><br>
> noinline (& in fact, even optnone) doesn't make sure the call happens -<br>
> various forms of IPA can cause a call to go away without actually inlining.<br>
><br>
> (simplest example, that even the inliner got wrong (& I fixed recently,<br>
> which is why any of this comes to mind/I have any context on it) - the<br>
> inliner removed a call to an optnone+readnone function without consulting<br>
> the inliner heuristic (this was in the alwaysinliner) because it assumed the<br>
> operation was so cheap no inliner heuristic would ever disagree, basically<br>
> ;) )<br>
><br>
> But some other optimization could/would still remove a noinline+readnone<br>
> function because it's a trivially dead instruction (assuming the result<br>
> isn't used). So noinline doesn't preserve the call - because some IPA can,<br>
> in some cases, be as powerful as inlining-ish.<br>
><br>
<br>
I agree, but still I don't think it's `noinline` job to prevent this<br>
from happening. It sounds weird (and probably a POLA violation) having<br>
`noinline` preventing interprocedural constant propagation.<br>
About `optnone`, I'm surprised is not powerful enough to prevent this<br>
from happening, modulo bugs of course. Do you have other examples?<br></blockquote><div><br>There were bugs. I fixed them. :) (specifically it was a combination of FunctionAttrs proving readnone on an optnone function - fixed. And the alwaysinliner killing trivially dead calls (so any function call with readnone, even without alwaysinline, could be 'inlined' (removed) by the alwaysinliner) - also fixed)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--<br>
Davide<br>
</blockquote></div></div>