<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 27, 2017 at 1:12 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Fri, Oct 27, 2017 at 1:08 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span>
    <p>On 10/27/2017 02:51 PM, Reid Kleckner
      wrote:<br></p>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div>Personally, I don't like the side effect intrinsic.</div>
      </div>
    </blockquote>
    <br></span>
    Understood. I also don't like the fact that it will clutter the IR
    in many cases.<span><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div> It will pollute all the IR generated by non-C frontends.
          What most of these frontends really want is just a switch to
          disable a targeted set of optimizations.</div>
        <div><br>
        </div>
        One thing I like about the function attribute idea is that it's
        conservatively correct to discard it when doing cross-language
        inlining. It just becomes something that C-family frontends need
        to remember to add to enable their special-case language rules,
        rather than something that non-C languages need to think about.
        Similar to the 'access', builtin vs nonbuiltin discussion
        happening in parallel, the attribute enables the optimization,
        rather than inhibiting it.</div>
    </blockquote>
    <br></span>
    As I said below, a function attribute is insufficient. It needs to
    be something we can mark per loop. This is needed to correctly model
    C. The sideeffect intrinsic is the best proposal I've seen so far.</div></blockquote><div><br></div></span><div>Maybe we should do both? If the intrinsic is a special case, that seems fine. It's cheap.</div></div></div></div>
</blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">As I understand it, part of the function attribute proposal is to change the default semantics of LLVM IR to have defined behavior on infinite loops, and then add an attribute opting into potential-UB. So if we do that, then the role of @llvm.sideeffect becomes a little subtle -- it'd be a way for a frontend for a language like C to opt into potential-UB for a function, but then opt out for individual loops in that function. Is that what you're proposing? If so, I'm ok taking that route.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Dan</div><div class="gmail_extra"><br></div></div>