<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 12/22/2014 11:22 AM, Reid Kleckner
      wrote:<br>
    </div>
    <blockquote
cite="mid:CACs=ty+HoSw6gaBLr+X8wAdAPZ=NyA3eZOJq4H3J9=wdpQt8XQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote"><br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir="auto">
                <div>As background to this extension idea, let me say
                  that I prefer the notion that developers, particularly
                  perf-aware developers like gamedevs, will want to
                  handle PGO via markup. The idea is for them to turn
                  PGO measurements into consciously-chosen markup, since
                  a given test run may not be fully expressive. (e.g.
                  They may not play the whole game through each time.)</div>
                <div><br>
                </div>
                <div>So the idea is to have the enum be marked with a
                  weight instead of just "impossible." The impossible
                  value would be perhaps -inf. I'd suggest that weights
                  could be either float 0 to 1 or 0 to 100, whichever
                  works best with the PGO infrastructure.</div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Personally, I don't think we need to conflate
              impossible and improbable. They seem different enough to
              warrant a second attribute. A separate "enum_probability"
              attribute is interesting, though.</div>
          </div>
        </div>
      </div>
    </blockquote>
    I will second this, but more strongly.  PGO is often sample based. 
    As a result, a 0% observed probability does not imply that the code
    is *always* unreachable.  Assuming otherwise would be incorrect. 
    Having a mechanism to distinguish between 'I've seen no samples
    here' and 'this code is guaranteed unreachable' is required for
    correctness.  <br>
    <br>
    As a bikeshed suggestion, why not name the impossible attribute
    [[unreachable]]?  We use that name for llvm_unreachable and related
    things.  The semantics are pretty much the same, just expressed
    slightly differently right?<br>
    <br>
    Actually, why can't you're objective be achieved using the existing
    llvm_unreachable mechanism?  Create a macro which expands to
    llvm_unreachable on all but one target, use that in the
    implementation of the case statement.  E.g.<br>
    case something_x86_specific: {<br>
      REACHABLE_ON_X86_ONLY();<br>
      .. actual code here<br>
    }<br>
    <br>
    Philip<br>
    <br>
    <br>
    <br>
    <br>
  </body>
</html>