[LLVMdev] [RFC] Stripping unusable intrinsics

Philip Reames listmail at philipreames.com
Mon Dec 22 11:36:47 PST 2014


On 12/22/2014 11:22 AM, Reid Kleckner wrote:
>
>     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.)
>
>     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.
>
>
> 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.
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.

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?

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.
case something_x86_specific: {
   REACHABLE_ON_X86_ONLY();
   .. actual code here
}

Philip




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141222/6d7b0ebc/attachment.html>


More information about the llvm-dev mailing list