[llvm-commits] [llvm] r42051 - in /llvm/trunk: lib/VMCore/Verifier.cpp test/CodeGen/Generic/GC/lower_gcroot.ll test/Verifier/gcread-ptrptr.ll test/Verifier/gcroot-alloca.ll test/Verifier/gcroot-meta.ll test/Verifier/gcroot-ptrptr.ll test/Verifier/gcwrite-ptrptr.ll

Gordon Henriksen gordonhenriksen at mac.com
Tue Sep 18 06:54:49 PDT 2007


On Sep 18, 2007, at 07:44, Duncan Sands wrote:

> Hi,
>
>>>> +static Value *StripBitCasts(Value *Val) {
>>>
>>> how about using IntrinsicInst::StripPointerCasts instead?
>>
>> Done. Note that, although there's tantalizing GEP-0 handling in
>> StripPointerCasts, it's still not really possible to use gcroot
>> without bitcasts:
>
> the reason for the GEP handling, is that if you have a constant  
> pointer P to a struct S for which the first field is of type T, and  
> you constant bitcast P to a T*, then the optimizers will turn this  
> into a GEP-0 instead of a bitcast.  Thus it is unwise to assume  
> you'll always see a bitcast - it might be that you get passed a GEP  
> instead.

This can never occur. This is a pointer to a pointer type, so gep 0  
can't be used for casts.

>> 	%x_addr = alloca %class.Derived*
>> 	%tmp0 = getelementptr %x_addr, i32 0, i32 0  ; Invalid! But nice  
>> try...
>
> If x_addr pointed to a global variable rather than a local  
> variable, this (or something like it) should be valid. Just to be  
> clear: I'm not suggesting that you can get rid of bitcasts - I'm  
> pointing out that in obscure circumstances you may be passed a GEP  
> rather than a bitcast, even if you always generate bitcasts in the  
> front-end.  So you need to handle that, eg by using StripPointerCasts.

Since gcroot is an annotation of a pointer alloca, this is not  
applicable. Although gep %alloca, 0 is now accepted, it is also  
necessarily redundant, and gep %alloca, 0, 0 is invalid by the  
definition.

Thanks,
Gordon




More information about the llvm-commits mailing list