[llvm-dev] virtual subregister liveness?

Quentin Colombet via llvm-dev llvm-dev at lists.llvm.org
Fri Aug 30 10:03:09 PDT 2019

> On Aug 30, 2019, at 8:31 AM, Jesper Antonsson via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> Hi,
> After dead-mi-elimination I'm experiencing a machine verifier failure 
> at this virtual subregister write:
>  %5.sub1 = COPY undef %11
> The machine verifier essentially complains that the rest of the
> register is undefined (a subregister write implies a "read" of the
> other parts).
> So the problem is that dead-mi-elimination has removed the previously
> existing defines of %5.sub0. Yet I'm unsure where the actual fault lies
> and I can't seem to find any documentation or list email that explains
> the modeling in detail. A few ideas:

If %5 is used in full, %5.sub0 is supposed to be defined before that use.
If %5.sub0 was defined with an implicit_def that means, IIRC, that we just miss an undef flag on %5.sub1 (undef in that case means that we don’t care about the contain of the other lane.)

Could you provide the MIR before and after dead-mi-elimination? Just the part where %5 is involved should suffice.

> Are there some restrictions on where dead-mi-elimination can be run?
> (I'm working with an out-of-tree target and we've put this failing
> dead-mi-elimination pass pretty soon after register coalescing.)
> Or is the use-list for %5 in MRI incorrectly constructed as it doesn't
> contain the remaining instruction? (These use-lists are what dead-mi-
> elimination is using to decide if an instruction is dead or not.)
> Or is the fault that there is no MO spelling out an implicit use
> %5.sub0?
> The actual verifier error is:
> *** Bad machine code: Virtual register defs don't dominate all uses.
> ***
> - function:    f
> - v. register: %5
> LLVM ERROR: Found 1 machine code errors.
> Thanks,
> Jesper
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

More information about the llvm-dev mailing list