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 _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits