[llvm-dev] Machine instruction verifier pass

[Nemanja Ivanovic via llvm-dev]

This kind of sounds like the peephole optimization should really be
resetting the kill flag if it's extending the live range of a [virtual]
register (which is what the description here seems to imply).

On Fri, May 5, 2017 at 9:54 AM, Jatin Bhateja via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hello Devs,
>
> Machine Instruction verifier pass always validates Live variable info
> associated with MachineInstr along with other checks.
>
> Please consider following scenario (w.r.t bugZilla 32583)
>
> 1/  MachineCSE pass may prohibit optimising out a common sub-expression
> for instruction using physical registers
> by looking at the LiveIn info of successor basic blocks.
>
> 2/ Which means we need Live Variables analysis to happen prior to
> executing MachineCSE.
>
> 3/ Live variable analysis associates Kill/def information with
> MachineOperands.
>
> 4/ In one of the regression Peephole optimizer (which does not uses
> liveness information)
> performs certain transformations over MachineBasicBlock which potentially
> dirties the
> liveness information computed early.
>
> 5/ Now, when Machine Instruction verifier kicks in after Peephole
> optimizer it reports use after kill violation
> over a particular instruction.
>
> Can we selectively turn of the live variable checking in Machine
> instruction verifier till next Live variable pass is invoked (as per the
> need of following pass).
>
> This may sound like defeating the purpose of machine instruction verifier
> which checks instruction validity against different parameters after each
> transformation pass, but if a pass does not use Live ness information
> should not be constrained to do other transformations which may dirty the
> live ness information.
>
> Please provide you comments.
>
> Thanks,
> Jatin Bhateja
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170517/9f8785e7/attachment.html>