[PATCH] Constant fold llvm.expect(c, ...) -> c
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>
> On Jan 26, 2015, at 10:30 AM, Chandler Carruth <chandlerc at google.com>
> On Mon, Jan 26, 2015 at 10:29 AM, Pete Cooper <peter_cooper at apple.com>
>> On Jan 26, 2015, at 10:24 AM, Chandler Carruth <chandlerc at google.com>
>> On Sun, Jan 25, 2015 at 9:37 PM, Pete Cooper <peter_cooper at apple.com>
>>> 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
> 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
> 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
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
> 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
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...
More information about the llvm-commits