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

Xinliang David Li via llvm-dev
2016-04-22T21:49:05Z

Your patch does make the handling of __builtin_unpredictable and
__builtin_expect 'unified' in some way.

However given the point brought up by Reid, and the rationale by Richard,
as well as consideration of the easiness for enhancement in the future, I
think keep the current mechanism is a better approach.

The test cases from Richard are broken with current lowering, but it is
just bugs to be fixed.

David

On Fri, Apr 22, 2016 at 1:50 PM, Sanjay Patel via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> I, of course, thought the ~100 lines added by D19299 was a reasonable
> trade for the ~800 lines removed in D19300.
>
> David Li (and anyone else following along), do you still like those
> patches after hearing this objection or should I abandon?
>
>
> On Fri, Apr 22, 2016 at 11:55 AM, Reid Kleckner <rnk at google.com>
wrote:
>
>> Sorry, I didn't realize that was the clang side.
>>
>> I think it's kind of ugly that the frontend has to pattern match
and
>> lower this intrinsic in three places: if, switch, and general case. The
>> existing intrinsic is nice because it directly represents what the user
can
>> write, and lets the optimizer decide how to best represent it. As David
Li
>> mentioned, we may want to do value profiling in the future, and if we
>> remove this intrinsic, we will have to come and revisit this code.
>>
>> I think a single early pass to lower this intrinsic is a low cost to
pay
>> for that simplicity.
>>
>> On Fri, Apr 22, 2016 at 10:39 AM, Sanjay Patel <spatel at
rotateright.com>
>> wrote:
>>
>>> Hi Reid -
>>>
>>> The intent of D19299 is to remove all Clang refs to llvm.expect. Do
you
>>> see any holes after applying that patch?
>>>
>>> On Fri, Apr 22, 2016 at 11:36 AM, Reid Kleckner <rnk at
google.com> wrote:
>>>
>>>> Clang still appears to use llvm.expect. I think if you can show
that
>>>> it's trivial to update clang with a patch, then yeah,
moving back down to
>>>> one representation for this sounds reasonable.
>>>>
>>>> On Fri, Apr 22, 2016 at 9:20 AM, Sanjay Patel via llvm-dev <
>>>> llvm-dev at lists.llvm.org> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>
>>>
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160422/e47f05c5/attachment.html>