llvm dev - Jan 2018 - MachineVerifier and undef

I'm working on getting an out of tree target machine verifier clean.
This has found some nasty bugs so I'd like to continue with it.

One instance of bad machine code is "Using an undefined physical
register". This arises whenever undef propagates to a machine
instruction. Usually this means the input was meaningless - e.g. call
an undefined address. Other times it's a consequence of optimising
vector code, e.g. converting <3 x float> into <4 x float> or
construction via IMPLICIT_DEF.

The signal to noise ratio on this is bad. E.g. storing an undefined
value to the stack is a missing optimisation, which is sad, but not
necessarily a reason to halt the compilation. Carefully removing every
instance of undef in DAGCombine helps but does not suffice because MIR
passes, notably subregister liveness tracking, reintroduce undef
values.

I think either I'm missing part of the handling of undef values
(should there be a MIR pass dedicated to removing them?) or I've
missed the goal of the verification pass. I'd like to enable it for
all internal testing. Perhaps it's intended more as an ad hoc
debugging aid.

How should I use a verifier pass that halts on undef when there are
lots of undef values? Advice would be welcome!

Thanks all

There are two things here: first are the <undef> operands, second are 
the verifier complaints.
As you have noticed, IMPLICIT_DEFs will eventually become the former. 
Register operands explicitly marked as undefined as treated as 
legitimately undefined, and they shouldn't trigger any errors.
The situations where the verifier detects an "undefined register" are 
cases where a register operand is not marked as undefined, and yet it's 
used without a prior definition in the code.  Prior definitions include 
block live-ins, explicit or implicit definitions in preceding 
instructions. They also include definitions of aliased registers, 
subregisters and superregisters. If none of these are present for a use 
of a (non-reserved) physical register, it is treated as an error in the 
code.

-Krzysztof

On 1/23/2018 5:29 AM, Jon Chesterfield via llvm-dev
wrote:
> I'm working on getting an out of tree target machine verifier clean.
> This has found some nasty bugs so I'd like to continue with it.
> 
> One instance of bad machine code is "Using an undefined physical
> register". This arises whenever undef propagates to a machine
> instruction. Usually this means the input was meaningless - e.g. call
> an undefined address. Other times it's a consequence of optimising
> vector code, e.g. converting <3 x float> into <4 x float> or
> construction via IMPLICIT_DEF.
> 
> The signal to noise ratio on this is bad. E.g. storing an undefined
> value to the stack is a missing optimisation, which is sad, but not
> necessarily a reason to halt the compilation. Carefully removing every
> instance of undef in DAGCombine helps but does not suffice because MIR
> passes, notably subregister liveness tracking, reintroduce undef
> values.
> 
> I think either I'm missing part of the handling of undef values
> (should there be a MIR pass dedicated to removing them?) or I've
> missed the goal of the verification pass. I'd like to enable it for
> all internal testing. Perhaps it's intended more as an ad hoc
> debugging aid.
> 
> How should I use a verifier pass that halts on undef when there are
> lots of undef values? Advice would be welcome!
> 
> Thanks all
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation