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

[Hal Finkel via llvm-commits]

hfinkel added a comment.

In http://reviews.llvm.org/D16263#328968, @loladiro wrote:

> 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'm obviously not against you pursuing a design that allows us to explicitly capture widening and then verify accordingly. However, if that is not immediately possible for whatever reason, loosening the constraint is also a potential solution in the mean time.

> 

> 

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


I understand; if we widen by direct type mutation (i.e. RAUW an instruction by an another of a different type while fixing everything else up) then we trigger this inconsistency with the debug information. If we widen by creating new variables to replace the old, and indvarsimplify does, then we essentially drop the debug info. Dropping the debug info does not trigger the problem, obviously, but it also means we've dropped the debug info (which is not really "better"). If we added code to indvarsimplify to attempt to preserve debug info (transfer the debug info associated with the old induction variables to the new ones) then, as I understand it, we'd end up triggering the same problem as you're seeing with CGP.


Repository:
  rL LLVM

http://reviews.llvm.org/D16263