[llvm-commits] [llvm] r46565 - in /llvm/trunk: lib/CodeGen/MachineModuleInfo.cpp test/DebugInfo/globalGetElementPtr.ll

[Chris Lattner]

On Jan 31, 2008, at 11:12 AM, Duncan Sands wrote:

>>>>> Hi Dale, maybe you could use IntrinsicInst::StripPointerCasts
>>>>> instead?
>>>>
>>>> Didn't know about this, thanks.  It recurses and I don't think  
>>>> that's
>>>> what I want in this case.  I did, however, steal its looping code:)
>>>
>>> Are you sure you don't want it to be recursive?  I can take a global
>>> variable, bitcast it, do a GEP 0 on that, bitcast the result, etc.
>>> The final result will be equivalent to a single bitcast of the
>>> original
>>> global.  So shouldn't this code handle it?  Of course if the
>>> optimizers
>>> are run then they would simplify such a silly example.  But it seems
>>> wrong to me to assume that the IR has been optimized...
>>
>>
>> No I'm not sure, but I know of no case where this is useful or
>> desirable.
>
> When linking, I vaguely recall that if a declaration of a global and
> the definition are not quite the same, uses of the declaration get  
> replaced
> with a bitcast of the definition (maybe I'm confusing with what's  
> done for
> functions).  If that declaration was itself bitcast to an i8* for  
> use in
> the debug intrinsic, you might end up with a double bitcast I  
> suppose.  All
> I'm saying is that it seems possible to me that double bitcasts  
> could be
> generated in practice (if rarely), and I don't see that it hurts to  
> handle
> them.  Plus you get to reduce code duplication by using  
> StripPointerCasts.
> Don't forget that code with debug info tends to be unoptimized, making
> pointless bitcast combinations more likely.

I'm not sure if there is a real issue here, but making it recursive is  
definitely safer.  Also, eliminating all of it by using  
StripPointerCasts would be best of all if it can be done.

-Chris