llvm dev - May 2017 - Machine instruction verifier pass

- Please do not add any more uses of the LiveVariables pass! It is deprecated
and only kept around for one last pass that isn't converted. All new code
should use LiveIntervalAnalysis!
- Kill flags are optional: If they are present they must be correct, but it is
legal to have a value die without having a kill flag on the operand. So often a
simple fix is to clear out the kill flags from instructions you touch instead of
recomputing them. The only downside is that some later passes will only perform
the maximum amount of optimization will kill flags present [1]

- Matthias

[1] Long term we want to get rid of kill flags completely which should clean up
a lot of code. But that is unfortunately a very tedious process, last time I
tried to switch the biggest user of killflags (RegisterScavenger) to a new
algorithm a powerpc stage2 buildbot broke and I never figured out why...
> On May 17, 2017, at 11:29 AM, Nemanja Ivanovic via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 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 <mailto: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 <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> 
> _______________________________________________
> 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/50660e2a/attachment.html>

Please see my replies embedded.

Thanks,
Jatin

On Thursday, May 18, 2017, Matthias Braun <mbraun at apple.com> wrote:
> - Please do not add any more uses of the LiveVariables pass! It is
> deprecated and only kept around for one last pass that isn't converted.
All
> new code should use LiveIntervalAnalysis!
> - Kill flags are optional: If they are present they must be correct, but
> it is legal to have a value die without having a kill flag on the operand.
> So often a simple fix is to clear out the kill flags from instructions you
> touch instead of recomputing them. The only downside is that some later
> passes will only perform the maximum amount of optimization will kill flags
> present [1]
>
>
PMDataManager keeps tracks of analysis requirements explicitely set by a
perticular pass by calling getAnaysisUsage for that pass i.e to either run
a specified analysis if its needed or preserve already performed analysis
through the execution of the pass if transformation is sure about not
dirtying the already computed analysis or simply allow invalidation of
analysis.

Once a pass in the optimization pipeline does not preserve already computed
analysis by calling setPreservedAll then any transformation occuring later
down the pipeline must recompute the required analysis.

However, if a pass does not call setPreserveAll then it does not own the
responsibility of updating the already computed analysis if it dirty it as
a side effect of some other transformation. This is exactly what is
happening in this case.  Livevariable analysis was called up the pipeline
so that MachineCSE could use the needed analysis. Peephole optimization
which is called later in the pipeline does not preserve not requires live
variables and dirty the liveness information as a side effect.

All is correct nothing wrong in the flow as if any other pass in pipeline
which need liveness will mention the same in its getAnalysisUsage and since
perticular analysis is not preserved by pass ahead of it in the
optimization pipeline hence it will get recomputed during schedulePass.

Now, MachineInstrVerifier pass which is a dumb validation pass always check
for consistency of liveness information attached to IR even if
transformation which ran just before it does not either require or preserve
i.e may invalidate liveness as a side effect.

Please refer to following citation from llvm documentation

http://llvm.org/docs/WritingAnLLVMPass.html#id38


- Matthias
>
> [1] Long term we want to get rid of kill flags completely which should
> clean up a lot of code. But that is unfortunately a very tedious process,
> last time I tried to switch the biggest user of killflags
> (RegisterScavenger) to a new algorithm a powerpc stage2 buildbot broke and
> I never figured out why...
>
Ok.
>
>
> On May 17, 2017, at 11:29 AM, Nemanja Ivanovic via llvm-dev <
> llvm-dev at lists.llvm.org
> <javascript:_e(%7B%7D,'cvml','llvm-dev at
lists.llvm.org');>> wrote:
>
> 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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','llvm-dev at
lists.llvm.org');>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> <javascript:_e(%7B%7D,'cvml','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/20170518/1069b294/attachment.html>

> On May 17, 2017, at 6:53 PM, Jatin Bhateja <jatin.bhateja at
gmail.com> wrote:
> 
> Please see my replies embedded.
> 
> Thanks,
> Jatin
> 
> On Thursday, May 18, 2017, Matthias Braun <mbraun at apple.com
<mailto:mbraun at apple.com>> wrote:
> - Please do not add any more uses of the LiveVariables pass! It is
deprecated and only kept around for one last pass that isn't converted. All
new code should use LiveIntervalAnalysis!
> - Kill flags are optional: If they are present they must be correct, but it
is legal to have a value die without having a kill flag on the operand. So often
a simple fix is to clear out the kill flags from instructions you touch instead
of recomputing them. The only downside is that some later passes will only
perform the maximum amount of optimization will kill flags present [1]
> 
>  
> PMDataManager keeps tracks of analysis requirements explicitely set by a
perticular pass by calling getAnaysisUsage for that pass i.e to either run a
specified analysis if its needed or preserve already performed analysis through
the execution of the pass if transformation is sure about not dirtying the
already computed analysis or simply allow invalidation of analysis.
> 
> Once a pass in the optimization pipeline does not preserve already computed
analysis by calling setPreservedAll then any transformation occuring later down
the pipeline must recompute the required analysis.
> 
> However, if a pass does not call setPreserveAll then it does not own the
responsibility of updating the already computed analysis if it dirty it as a
side effect of some other transformation. This is exactly what is happening in
this case.  Livevariable analysis was called up the pipeline so that MachineCSE
could use the needed analysis. Peephole optimization which is called later in
the pipeline does not preserve not requires live variables and dirty the
liveness information as a side effect.
> 
> All is correct nothing wrong in the flow as if any other pass in pipeline
which need liveness will mention the same in its getAnalysisUsage and since
perticular analysis is not preserved by pass ahead of it in the optimization
pipeline hence it will get recomputed during schedulePass.
> 
> Now, MachineInstrVerifier pass which is a dumb validation pass always check
for consistency of liveness information attached to IR even if transformation
which ran just before it does not either require or preserve i.e may invalidate
liveness as a side effect.
Sure. However:

- The result of an analysis pass is part of that pass instance. I.e. accessing
LiveVariables::getVarInfo() is clearly getting you the result of LiveVariables.
- However as far as I understand you this is about kill flags on machine
operands? They are part of the normal MI representation. I don't consider
those to be the result of the LiveVariables analysis but a part of MI that
should always be correct (I know in practices things are somewhat messy as the
big number of addPass(XXX, false) invocations in TargetPassConfig
demonstrates...)

- Matthias

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170518/b58000a0/attachment-0001.html>