<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 06/29/2017 12:43 PM, Peter Lawrence
      wrote:<br>
    </div>
    <blockquote
      cite="mid:D41961C0-953F-403B-8C09-A9192DD4DABB@sbcglobal.net"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <br class="">
      <div>
        <blockquote type="cite" class="">
          <div class="">On Jun 29, 2017, at 9:32 AM, Hal Finkel <<a
              moz-do-not-send="true" href="mailto:hfinkel@anl.gov"
              class="">hfinkel@anl.gov</a>> wrote:</div>
          <br class="Apple-interchange-newline">
          <div class="">
            <div class="moz-cite-prefix" style="font-family: Helvetica;
              font-size: 12px; font-style: normal; font-variant-caps:
              normal; font-weight: normal; letter-spacing: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;
              background-color: rgb(255, 255, 255);"><br
                class="Apple-interchange-newline">
              On 06/29/2017 10:41 AM, Peter Lawrence wrote:<br class="">
            </div>
            <blockquote
              cite="mid:8D1216F2-8E1C-4895-8DA2-19932A92BD1B@sbcglobal.net"
              type="cite" style="font-family: Helvetica; font-size:
              12px; font-style: normal; font-variant-caps: normal;
              font-weight: normal; letter-spacing: normal; orphans:
              auto; text-align: start; text-indent: 0px; text-transform:
              none; white-space: normal; widows: auto; word-spacing:
              0px; -webkit-text-size-adjust: auto;
              -webkit-text-stroke-width: 0px; background-color: rgb(255,
              255, 255);" class=""><br class="">
              <div class="">
                <blockquote type="cite" class="">
                  <div class="">On Jun 29, 2017, at 4:39 AM, Hal Finkel
                    <<a moz-do-not-send="true"
                      href="mailto:hfinkel@anl.gov" class="">hfinkel@anl.gov</a>>
                    wrote:</div>
                  <br class="Apple-interchange-newline">
                  <div class="">
                    <div bgcolor="#FFFFFF" text="#000000" class="">
                      <div class="moz-cite-prefix">On 06/28/2017 05:33
                        PM, Peter Lawrence wrote:<br class="">
                      </div>
                      <blockquote
                        cite="mid:37027DE0-B3CC-47C2-907C-C5A7A5A97BD1@sbcglobal.net"
                        type="cite" class="">Chandler,
                        <div class="">               where we disagree
                          is in whether the current project is moving
                          the issue</div>
                        <div class="">forward.  It is not.  It is making
                          the compiler more complex for no additional
                          value.</div>
                        <div class=""><br class="">
                        </div>
                        <div class="">The current project is not based
                          in evidence, I have asked for any SPEC
                          benchmark</div>
                        <div class="">that shows performance gain by the
                          compiler taking advantage of “undefined
                          behavior”</div>
                        <div class="">and no one can show that.</div>
                      </blockquote>
                      <br class="">
                      I can't comment on SPEC, but this does remind me
                      of code I was working on recently. To abstract the
                      relevant parts, it looked something like this:<br
                        class="">
                      <br class="">
                      template <typename T><br class="">
                      int do_something(T mask, bool cond) {<br class="">
                       <span class="Apple-converted-space"> </span>if
                      (mask & 2)<br class="">
                         <span class="Apple-converted-space"> </span>return
                      1;<br class="">
                      <br class="">
                       <span class="Apple-converted-space"> </span>if
                      (cond) {<br class="">
                         <span class="Apple-converted-space"> </span>T
                      high_mask = mask >> 48;<br class="">
                         <span class="Apple-converted-space"> </span>if
                      (high_mask > 5)<br class="">
                           <span class="Apple-converted-space"> </span>do_something_1(high_mask);<br
                        class="">
                         <span class="Apple-converted-space"> </span>else
                      if (high_mask > 3)<br class="">
                           <span class="Apple-converted-space"> </span>do_something_2();<br
                        class="">
                       <span class="Apple-converted-space"> </span>}<br
                        class="">
                      <br class="">
                       <span class="Apple-converted-space"> </span>return
                      0;<br class="">
                      }<br class="">
                      <br class="">
                      This function ended up being instantiated on
                      different types T (e.g. unsigned char, unsigned
                      int, unsigned long, etc.) and, dynamically, cond
                      was always false when T was char. The question is:
                      Can the compiler eliminate all of the code
                      predicated on cond for the smaller types? In this
                      case, this code was hot, and moreover, performance
                      depended on the fact that, for T = unsigned char,
                      the function was inlined and the branch on cond
                      was eliminated. In the relevant translation unit,
                      however, the compiler would never see how cond was
                      set.<br class="">
                      <br class="">
                      Luckily, we do the right thing here currently. In
                      the case where T = unsigned char, we end up
                      folding both of the high_mask tests as though they
                      were false. That entire part of the code is
                      eliminated, the function is inlined, and everyone
                      is happy.<br class="">
                      <br class="">
                      Why was I looking at this? As it turns out, if the
                      'else if' in this example is just 'else', we don't
                      actually eliminate both sides of the branch. The
                      same is true for many other variants of the
                      conditionals (i.e. we don't recognize all of the
                      code as dead).</div>
                  </div>
                </blockquote>
                <div class="">
                  <div class=""><br class="">
                  </div>
                  <div class=""><br class="">
                  </div>
                  <div class="">I apologize in advance if I have missed
                    something here and am misreading your example...</div>
                  <div class=""><br class="">
                  </div>
                </div>
                <div class="">This doesn’t make sense to me, a shift
                  amount of 48 is “undefined” for unsigned char,</div>
                <div class="">How do we know this isn’t a source code
                  bug,</div>
                <div class="">What makes us think the the user intended
                  the result to be “0”.</div>
              </div>
            </blockquote>
            <br style="font-family: Helvetica; font-size: 12px;
              font-style: normal; font-variant-caps: normal;
              font-weight: normal; letter-spacing: normal; orphans:
              auto; text-align: start; text-indent: 0px; text-transform:
              none; white-space: normal; widows: auto; word-spacing:
              0px; -webkit-text-stroke-width: 0px; background-color:
              rgb(255, 255, 255);" class="">
            <span style="font-family: Helvetica; font-size: 12px;
              font-style: normal; font-variant-caps: normal;
              font-weight: normal; letter-spacing: normal; orphans:
              auto; text-align: start; text-indent: 0px; text-transform:
              none; white-space: normal; widows: auto; word-spacing:
              0px; -webkit-text-stroke-width: 0px; background-color:
              rgb(255, 255, 255); float: none; display: inline
              !important;" class="">As I said, this is representation of
              what the real code did, and looked like, after other
              inlining had taken place, etc. In the original form, the
              user's intent was clear. That code is never executed when
              T is a small integer type.</span><br style="font-family:
              Helvetica; font-size: 12px; font-style: normal;
              font-variant-caps: normal; font-weight: normal;
              letter-spacing: normal; orphans: auto; text-align: start;
              text-indent: 0px; text-transform: none; white-space:
              normal; widows: auto; word-spacing: 0px;
              -webkit-text-stroke-width: 0px; background-color: rgb(255,
              255, 255);" class="">
          </div>
        </blockquote>
        <br class="">
      </div>
      <div><br class="">
      </div>
      <div>I will still have a hard time believing this until I see a
        real example, can you fill in the details ?</div>
    </blockquote>
    <br>
    As I recall, it was roughly like this: There is some collection of
    objects that have some flags (stored in a bit mask). Some of these
    objects optionally supported tracing, and for such objects, the
    tracing flags are stored in the high bits of the bit mask. Some of
    the low bits had universal meanings. For objects that didn't support
    tracing at all, they used a smaller bit mask (to save on space,
    etc.). External logic guaranteed that the tracing bits were only
    checked for objects that supported tracing (in addition to other
    conditions being true). There was a template class that handled the
    bit masks and interpreted some of the tracing bits (on supported
    objects, but only if tracing was enabled). This function was a
    member of that template class. The 48 was not directly specified in
    the function like this, but was a parameter, and so only appeared
    like this after inlining.<br>
    <br>
     -Hal<br>
    <br>
    <blockquote
      cite="mid:D41961C0-953F-403B-8C09-A9192DD4DABB@sbcglobal.net"
      type="cite">
      <div><br class="">
      </div>
      <div><br class="">
      </div>
      <div>Peter Lawrence.</div>
      <div><br class="">
      </div>
      <div><br class="">
      </div>
      <div><br class="">
      </div>
      <div><br class="">
      </div>
      <br class="">
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
  </body>
</html>