<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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 class="">
    <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 class=""><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><div>Maybe we should do both? If the intrinsic is a special case, that seems fine. It's cheap.</div></div></div></div>