We should use the information provided by the gcc __builtin_expect function. This involves adding some mechanism for encoding the information in the LLVM IR (most likely an intrinsic) and updating llvm-gcc and clang to emit this information.
Retitling bug, we already "support" it, the idea is to use it for something.
Bob, is this done?
Sure, we can call it done. We currently only use it for a few things but the infrastructure is in place, along with a few uses.
This is not yet done... It's a bit hard to prove to yourself that it is not done by running a command because we have few optimizations using the information, but I've added a testing layer that demonstrates that in fact metadata produced by the LLVM expect intrinsic does not get incorporated into the branch probability analysis, or consequentially into the block frequency analysis, or any optimizations we do have using them. I'm mailing patches to cfe-commits which will bridge this gap in the infrastructure, and I've already fixed a critical bug in branch probabilities that would have led to turning this on producing exactly *backwards* probabilities, pessimizing code instead of optimizing it. See r142168 for that bit of fun.
I explained the situation on the dev list back in August: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-August/042863.html It was well-known that BranchInst::swapSuccessors is broken under the current meta data scheme, and who knows what else. I'm looking at Chandler's patch now.
Cloned to rdar://10308394
Fixed with the following commits: r142168 -- fix most egregious corruption of probability metadata r142491 -- add testing facility to ensure we actually get expect into probabilities r142492 -- add support for expects which feed branches to the probability analysis r142493 -- add support for expects which feed switches to the probability analysis We're now back to the state of 1) the probabilities haven't been completely audited, and 2) we only have a few passes that take advantage of them. But that was the desired state for closing this PR. __builtin_expect now influences code generation. Chris, you had expressed an interest in pulling these into 3.0 -- it seems somewhat borderline to me though. I'll leave the decision to you and Bill to sort out. =]
Bill, if this is actually completely broken in LLVM 3.0 and causing us to pessimize code, I'd recommend taking this. Ultimately it's your call though.
(In reply to comment #8) > Bill, if this is actually completely broken in LLVM 3.0 and causing us to > pessimize code From what I can tell, the 3.0 code is not pessimized really. While it is "completely broken" in that __builtin_expect data is completely ignored and has no impact on any parts of the optimizer, it doesn't have a negative impact. The bugs I fixed here didn't impact the probability information (purely heuristic based) that *is* currently active in 3.0, so the bug fixes alone are not worth merging.
*** Bug 11096 has been marked as a duplicate of this bug. ***