[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
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
More information about the llvm-dev
mailing list