[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