[cfe-dev] [llvm-dev] [RFC] remove the llvm.expect intrinsic

[Philip Reames via cfe-dev]

On 04/22/2016 09:20 AM, Sanjay Patel via llvm-dev wrote:
> I've proposed removing the llvm.expect intrinsic:
> http://reviews.llvm.org/D19300
>
> The motivation for this change is in:
> http://reviews.llvm.org/D19299
>
> For reference:
> 1. We created an intrinsic that's only reason for existing is to 
> improve perf, but the intrinsic can harm optimization by interfering 
> with transforms in other passes.
I don't follow this at all.  Given expects are eagerly lowered to 
metadata, where's the interaction?  In particular, the expect lowering 
overrules any metadata on the associated branch/switch. This is exactly 
what you'd expect for a user annotation interacting with PGO data.
>
> 2. To solve that, we created a pass to always transform the intrinsic 
> into metadata at a very early stage in LLVM. But now every program is 
> paying a compile-time tax (running the LowerExpectIntrinsic pass) for 
> a feature that is rarely used.
Er, what cost?  Given this is a single linear pass over the IR - and 
could actually be made essentially free by checking to see if the module 
has any uses of expect - I'm suspicious of this compile time argument.  
Have you actually seen this in profiles?
>
> A possible front-end replacement transformation for a source-level 
> "builtin_expect()" is in D19299: I think a front-end can always 
> directly create metadata for this kind of programmer hint rather than 
> using an intermediate representation (the intrinsic). Likewise, if 
> there's some out-of-tree IR pass that is creating an llvm.expect, it 
> should be able to create branch weight metadata directly instead.
This seems like a reasonable proposal.  The expect intrinsic does give 
us a mechanism to express value profiling predictions, but we don't 
appear to actually use that today.  My bias would be to leave it in 
place, but I'm not going to object strongly if the consensus goes the 
other way.
>
> Please let me know if you see any problems with this proposal or the 
> patches.
>
> For reference, here's the original post-commit review thread for 
> llvm.expect:
> https://marc.info/?l=llvm-commits&m=130997676129580&w=4
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160422/3f5bd5d0/attachment.html>