Question about addr capture

Shuxin Yang shuxin.llvm at gmail.com
Sat Mar 23 11:04:17 PDT 2013


Hi, Duncan:

    Thanks!  The example you give in this mail is exactly the one Arnold 
show to me.
I think even a points-to analysis fail to prove if p and q may points to 
same place.
For now, I have to be conservative. But I will highlight the trick in my 
code lest potential
readers ask the same question again & again.

Thanks
Shuxin

On 3/23/13 12:17 AM, Duncan Sands wrote:
> Hi Shuxin,
>
> On 22/03/13 22:48, Shuxin Yang wrote:
>> Hi,
>>
>>    Arnold just show me a crazy contrived example which I think it is 
>> really
>> hard, if not impossible, to analyze.
>
> there are many crazy examples, which is why the logic is so conservative.
> However when it was first written there was a debate about whether it has
> to be so conservative, since language rules can save you.  For example,
> suppose you take a C pointer P and decompose it one bit at a time, then
> recompose a new pointer Q from those bits, so Q == P.  I'm told that the
> C standard says the compiler is allowed to assume that Q and P don't 
> alias.
> At the time it was decided not to exploit this kind of thing, but if you
> have some important test cases that would benefit from it, it might be 
> worth
> reconsidering [*].
>
> Ciao, Duncan.
>
> [*] As usual, the problem with language rules is that every language has
> different rules, so it is necessary to set this up in such a way that 
> every
> language can get what it wants.  That's probably pretty painful.
>
>> Thank you all for the input.
>>
>> Shuxin
>>
>> On 3/22/13 1:45 PM, Duncan Sands wrote:
>>> Hi Shuxin,
>>>
>>> On 22/03/13 18:56, Shuxin Yang wrote:
>>>> Hi, list:
>>>>
>>>>       Would someone shed some light on the following code. How can 
>>>> an address
>>>> be captured via icmp?
>>>
>>> using icmp you can determine each bit of the value, one by one, and 
>>> then
>>> reconstruct the value from those bits.
>>>
>>> Ciao, Duncan.
>>>
>>> PS: I think there are some fairly comprehensive test cases for 
>>> capture tracking,
>>> and they are commented IIRC.  If you disable some logic, like this, 
>>> you should
>>> see a test case fail.  Hopefully it should then become clear from 
>>> the test case
>>> what the issue is.
>>>
>>>>
>>>> Thanks
>>>> Shuxin
>>>>
>>>> cat -n lib/Analysis/CaptureTracking.cpp
>>>> ==========================
>>>> 157     case Instruction::ICmp:
>>>> 158       // Don't count comparisons of a no-alias return value 
>>>> against null as
>>>> 159       // captures. This allows us to ignore comparisons of 
>>>> malloc results
>>>> 160       // with null, for example.
>>>> 161       if (isNoAliasCall(V->stripPointerCasts()))
>>>> 162         if (ConstantPointerNull *CPN =
>>>> 163 dyn_cast<ConstantPointerNull>(I->getOperand(1)))
>>>> 164           if (CPN->getType()->getAddressSpace() == 0)
>>>> 165             break;
>>>> 166       // Otherwise, be conservative. There are crazy ways to 
>>>> capture
>>>> pointers
>>>> 167       // using comparisons.
>>>> 168       if (Tracker->captured(U))
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>




More information about the llvm-commits mailing list