[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