[PATCH] D16263: [CodeGenPrepare] Also consider metadata uses

[Keno Fischer via llvm-commits]

loladiro added a comment.

In http://reviews.llvm.org/D16263#328880, @hfinkel wrote:

> In http://reviews.llvm.org/D16263#328826, @loladiro wrote:
>
> > Say you're splitting an Alloca of a 64bit thing into 2 32bit things, SROA, will rewrite the debug info to say, ok, the lower 32bits are here, the upper 32bits are there. Now, if the variable is only declared to be 32bits in debug info, the verifier and backend will barf and say, "hey the piece you're describing is outside of the range of this variable".
>
>
> Maybe we should just drop those pieces instead of asserting?


Perhaps, but I don't think that's a particularly sounds design, because that also means we drop cases where there are legitimate bugs in transformations or the frontend.

> >   I had a quick look at indvarsimplify, but as far as I can tell it inserts compensating truncs in all cases, so does not suffer from this problem (but I only had a cursory look, somebody else might have to answer whether it ever RAUWs a value with a value of a different size).

> 

> 

> It inserts truncs when there are other users it can't also widen; but it does generate new instructions instead of mutating the type of an existing instruction.

> 

> However, based on what you're telling me, this is worse (in a sense), because it implies that we're losing debug info on the induction variable when we do this. If we were to update indvarsimplify to attempt to preserve more debug info, we'd run into the same problem?


Not sure I understand what you're saying here (probably just because I'm not familiar with the pass). The problem here occurs if you RAUW an instruction of some type by an instruction of a larger (or smaller type).


Repository:
  rL LLVM

http://reviews.llvm.org/D16263