<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 04/22/2016 09:20 AM, Sanjay Patel
via llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:CA+wODivcJBKGR5gyXgv_gP3ZZBFDhX3zdoV-Tijb71=RReCBEA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>I've proposed removing the llvm.expect intrinsic:<br>
<a moz-do-not-send="true"
href="http://reviews.llvm.org/D19300">http://reviews.llvm.org/D19300</a><br>
<br>
</div>
The motivation for this change is in:<br>
<a moz-do-not-send="true"
href="http://reviews.llvm.org/D19299">http://reviews.llvm.org/D19299</a><br>
<br>
For reference:<br>
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.<br>
</div>
</div>
</blockquote>
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.<br>
<blockquote
cite="mid:CA+wODivcJBKGR5gyXgv_gP3ZZBFDhX3zdoV-Tijb71=RReCBEA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
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.<br>
</div>
</div>
</blockquote>
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? <br>
<blockquote
cite="mid:CA+wODivcJBKGR5gyXgv_gP3ZZBFDhX3zdoV-Tijb71=RReCBEA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
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.<br>
</div>
</div>
</blockquote>
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. <br>
<blockquote
cite="mid:CA+wODivcJBKGR5gyXgv_gP3ZZBFDhX3zdoV-Tijb71=RReCBEA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
Please let me know if you see any problems with this proposal
or the patches.<br>
<br>
</div>
<div>For reference, here's the original post-commit review
thread for llvm.expect:<br>
<a moz-do-not-send="true"
href="https://marc.info/?l=llvm-commits&m=130997676129580&w=4"
class="" target="_blank" rel="noreferrer">https://marc.info/?l=llvm-commits&m=130997676129580&w=4</a><br>
<br>
</div>
<div><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>