[llvm-dev] Liveness Analysis
Matthias Braun via llvm-dev
llvm-dev at lists.llvm.org
Wed Sep 26 10:24:38 PDT 2018
> On Sep 26, 2018, at 6:01 AM, Björn Pettersson A <bjorn.a.pettersson at ericsson.com> wrote:
>
> So what is the status about LiveVariables. Is there a plan to remove it?
>
> After searching in old lvm-dev-mails it is mentioned that LiveVariable
> still exists due to one pass needing it. And a comment in
> TargetPassConfig.cpp indicates that the pass in question is
> TwoAddressInstruction:
>
> // FIXME: Once TwoAddressInstruction pass no longer uses kill flags,
> // LiveVariables can be removed completely, and LiveIntervals can be directly
> // computed. (We still either need to regenerate kill flags after regalloc, or
> // preferably fix the scavenger to not depend on them).
Yes as far as I know this is the last pass. PHIElimination uses it too today, but it supports both and actually works, while TwoAddress AFAIK is broken with LiveIntervals mostly because of target callbacks I think.
I believe the talk about kill flags in the comment to not be true anymore (we regenerate the kill flags anyway in virtregrewrite which comes before the scavenger and I switch the scavenger to not rely on them anymore in nearly all cases).
>
>
> When looking in TwoAddressInstructionPass.cpp it looks like the pass only
> use/update LV when there is no LIS. And there seems to be an experimental
> -early-live-intervals option to calculcate LIS before
> TwoAddressInstructionPass.
>
> I also noticed that the -early-live-intervals option was added back in 2012.
> So I assume that the plans to replace LiveVariables by LiveIntervals
> in TwoAddressInstructionPass got some history.
>
> Has there been any evaluation (lately) from using -early-live-intervals?
Unfortunately the work wasn’t finished in 2012 and As far as I know noone else really attempted it seriously since then.
>
>
> I got a feeling that the SSA deconstruction passes are overly complicated
> right now, since for example PHIElimination tries to update both LV and
> LIS conditionally depending on if the analyses are available or not.
> But there are no test cases that set -early-live-intervals afaict, so
> there is a bulk of code that seems to not be regression tested related
> to LIS in PHIElimination and TwoAddressInstructionPass.
>
> Given that no one is still actively working on removing LiveVariables;
> Maybe it is better to remove -early-live-intervals and the not
> so well tested code regarding LIS in PHIElimination/TwoAddressInstructionPass.
> And then we could say that LiveVariables should be used during SSA
> deconstruction (instead of saying that it is deprecated).
Are you planning bigger changes to these passes? I feel like removing the LIS code is admitting defeat and cementing the worse system... On the other hand if it becomes in the way of making changes we could discuss dropping it...
- Matthias
>
> /Björn
>
>
>> -----Original Message-----
>> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Matthias
>> Braun via llvm-dev
>> Sent: den 20 september 2018 22:23
>> To: Jason Ott <jott002 at ucr.edu>
>> Cc: llvm-dev at lists.llvm.org
>> Subject: Re: [llvm-dev] Liveness Analysis
>>
>> Assuming you talk about the machine representation:
>> - The register allocators use the LiveIntervals analysis (there is also
>> LiveVariables but that is deprecated, please don't use it).
>> - When register allocation is done we keep the block live-in lists around
>> and you can use LivePhysReg or LiveRegUnits to recompute the liveness
>> information in the middle of a basic block when necessary.
>> - The RDF framework in lib/Target/Hexagon performs a dataflow analysis
>> post-regalloc to determine values in physical registers.
>>
>> - Matthias
>>
>>> On Sep 20, 2018, at 11:31 AM, Jason Ott via llvm-dev <llvm-
>> dev at lists.llvm.org> wrote:
>>>
>>> Where is the liveness analysis pass? I have been looking for days but
>> cannot find anything.
>>>
>>> I just want to know transfer variables in and out of basic blocks, that
>> are calculated using simple data flow equations.
>>>
>>> Thanks!
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> 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
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
More information about the llvm-dev
mailing list