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

[Pete Cooper]

> On Jan 26, 2015, at 11:19 AM, Chandler Carruth <chandlerc at google.com> wrote:
> 
> On Mon, Jan 26, 2015 at 10:59 AM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at apple.com>> wrote:
> 
>> On Jan 26, 2015, at 10:30 AM, Chandler Carruth <chandlerc at google.com <mailto:chandlerc at google.com>> wrote:
>> 
>> 
>> On Mon, Jan 26, 2015 at 10:29 AM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at apple.com>> wrote:
>>> On Jan 26, 2015, at 10:24 AM, Chandler Carruth <chandlerc at google.com <mailto:chandlerc at google.com>> wrote:
>>> 
>>> 
>>> On Sun, Jan 25, 2015 at 9:37 PM, Pete Cooper <peter_cooper at apple.com <mailto: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 ::
That would be nice.  I expect (ha!) that we’d do this in IRGen.  I might look in to this, although i’m not too familiar with clang.

If you’re interested, i’ve worked out why I see this benefit at all in this patch.  I LTO my Debug LLVM.  This results in -O0 on the bitcode produced by LLVM, but then the linker LTO’s with optimizations enabled.  And because LTO doesn’t have LowerExpect in its pipeline, I see many cases of 'call i64 @llvm.expect.i64(i64 1, i64 1)’ in my IR.

So, getting the front-end to generate metadata would certainly fix this.  As would calling LowerExpect in libLTO or in populateFunctionPassManager even when on -O0.  Or we could just say that a Debug LTO build should live with this issue, although I’d prefer one of the other options to this one.

Pete

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150126/0cf963fc/attachment.html>