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

Duncan Sands baldrick at free.fr
Thu Jan 31 11:12:07 PST 2008


> >>> 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.

> The code in question is handling the debug info for global variables,  
> specifically the part that points to the global variable itself.   
> That's under the control of the front ends, although the optimizers  
> can do simplifications.  I don't think there's a need to handle more  
> general expressions here.

I understand where you're coming from, but I can't help suspecting that
this is going to blow up for some poor person in obscure circumstances.
I don't feel strongly about it though.

Ciao,

Duncan.



More information about the llvm-commits mailing list