[PATCH] Constant fold llvm.expect(c, ...) -> c

Chandler Carruth chandlerc at google.com
Mon Jan 26 11:19:43 PST 2015


On Mon, Jan 26, 2015 at 10:59 AM, Pete Cooper <peter_cooper at apple.com>
wrote:

>
> On Jan 26, 2015, at 10:30 AM, Chandler Carruth <chandlerc at google.com>
> wrote:
>
>
> On Mon, Jan 26, 2015 at 10:29 AM, Pete Cooper <peter_cooper at apple.com>
> wrote:
>
>> On Jan 26, 2015, at 10:24 AM, Chandler Carruth <chandlerc at google.com>
>> wrote:
>>
>>
>> On Sun, Jan 25, 2015 at 9:37 PM, Pete Cooper <peter_cooper at apple.com>
>> wrote:
>>
>>> Hi hfinkel,
>>>
>>> This teaches the constant folder that an llvm.expect intrinsic with a
>>> constant as the first operand will return that constant.
>>>
>>> This reduces the size of an LTO'd llc by over 1% due to branches which
>>> can be removed once the constant is propagated.
>>>
>>
>> I really don't understand this.
>>
>> The design llvm.expect was specifically for LowerExpect to remove *all*
>> of these intrinsics from the IR? Why isn't that working?
>>
>> Looks like LowerExpect is only added in populateFunctionPassManager,
>> which is only called by clang, opt, and bug point.  There’s no call to this
>> in llvm-lto.
>>
>> I still think its worthwhile to constant fold expect as soon as possible
>> as this patch does, but it looks like we also need that pass in the LTO
>> pipeline.
>>
>
> I really don't think it is. We should be running LowerExpect really early
> in every single pass pipeline because, as you saw, there are tons of passes
> we would have to teach about it otherwise. Not constant folding is, if
> anything, a nice way to flush these issues out.
>
> I see what you mean.  Personally I find that a bit gross that we have an
> intrinsic for this at all then.
>

I kind-of do too... But at the time it went in, it was "hard" to connect
these dots.


>
> If anyone is curious, these are the passes 'opt -O2' runs up to
> LowerExpect.  So the SimplifyCFG here for example is possibly missing the
> opportunity to do some useful work because of the expects.
>

Fortunately, we run simplify-cfg again at the start of the module pass
manager.

The reason we do things in this order:


>
> Pass Arguments:  -datalayout -notti -basictti -x86tti -no-aa -tbaa
> -scoped-noalias -assumption-cache-tracker -targetlibinfo -basicaa -verify
> -simplifycfg -domtree -sroa -early-cse -lower-expect
> Data Layout
> No target information
> Target independent code generator's TTI
> X86 Target Transform Info
> No Alias Analysis (always returns 'may' alias)
> Type-Based Alias Analysis
> Scoped NoAlias Alias Analysis
> Assumption Cache Tracker
> Target Library Information
> Basic Alias Analysis (stateless AA impl)
>   FunctionPass Manager
>     Module Verifier
>     Simplify the CFG
>     Dominator Tree Construction
>     SROA
>     Early CSE
>     Lower 'expect' Intrinsics
>

Is because 1) SROA isn't heavily impacted by expect intrinsics, and 2) we
want simplify-cfg to have "normalized" the CFG enough to more easily attach
the expect intrinsic to the eventual branch or switch.

However, I suspect (without evidence sadly) that we could get all of the
benifit from just running simplify-cfg + lower-expect, and then running the
rest afterward.

I also suspect that with minimal effort (again, without evidence) we could
just generate weights on branches rather than using the expect
intrinsic.... :: shrug ::
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150126/a9adef00/attachment.html>


More information about the llvm-commits mailing list