[llvm-dev] MachineVerifier and undef

Krzysztof Parzyszek via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 23 05:41:06 PST 2018

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 


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

More information about the llvm-dev mailing list