[llvm-commits] [llvm] r134516 - in /llvm/trunk: include/llvm/ include/llvm/Support/ include/llvm/Transforms/ lib/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Transforms/Scalar/ lib/Transforms/Utils/ lib/VMCore/ test/CodeGen/Generic/ test/Transforms/LowerExpectIntrinsic/

Andrew Trick atrick at apple.com
Tue Jul 12 16:01:00 PDT 2011


On Jul 12, 2011, at 2:24 PM, Jakub Staszak wrote:

> Hi Andy,
> 
> Optimizations can always be harmed by intrinsics (e.g. Instruction Combiner). Because of that we remove expect intrinsics at the same beginning before any optimizations.
> 
> -Kuba

Part of the answer to my question is that the intrinsic replaces the uses of the original value. Naturally that's a serious problem for anyone following the def-use chain. I'm not sure why you wanted to define the intrinsic that way. Presumably because we can't pin it to a block?

Ideally you want a positional intrinsic interpreted as such: the value operand takes on the expected constant on any path dominated by the intrinsic. There should be no need to violate the def-use chain.

-Andy

> On Jul 12, 2011, at 2:01 PM, Andrew Trick wrote:
> 
>> 
>> On Jul 7, 2011, at 1:48 PM, Jakub Staszak wrote:
>>> Right now clang creates "expect" intrinsic for every __builtin_expect instruction. These intrinsics must be lowered early because in other case they can harm other optimizations. During the lowering we also create "branch_weight" metadata, which can be used by other optimizations using BranchProbability analysis.
>> 
>> Kuba,
>> 
>> Which optimizations are harmed by expect intrinsics?
>> 
>> If this is just a temporary solution, that's fine. In the long term, we need to formalize the properties of intrinsics that serve as positional meta-data. This is needed for debug info, exception handling, lifetimes, profiling, and probably more to come. We should have a uniform framework for these that guarantee they maintain their association with a control flow edge without affecting any optimizations or heuristics. BasicBlock::getFirstNonPHIOrDbgOrLifetime is a glaring example of the need for a general solution.
>> 
>> Three representations of almost exactly the same information (intrinsics, meta-data, and analysis) is also evidence of a design shortcoming.
>> 
>> -Andy
>> 
>>> On Jul 6, 2011, at 5:31 PM, Chris Lattner wrote:
>>> 
>>>> 
>>>> On Jul 6, 2011, at 11:22 AM, Jakub Staszak wrote:
>>>> 
>>>>> Author: kuba
>>>>> Date: Wed Jul  6 13:22:43 2011
>>>>> New Revision: 134516
>>>>> 
>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=134516&view=rev
>>>>> Log:
>>>>> Introduce "expect" intrinsic instructions.
>>>>> 
>>>> 
>>>> Hi Kuba,
>>>> 
>>>> Why is this introducing a new pass to do lowering?
>>>> 
>>>> -Chris
>>> 
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110712/1cb8e3d3/attachment.html>


More information about the llvm-commits mailing list