Another problem with "Recommit r265547, and r265610,r265639,r265657"
Quentin Colombet via llvm-commits
llvm-commits at lists.llvm.org
Wed Apr 27 15:01:39 PDT 2016
> On Apr 27, 2016, at 2:53 PM, Wei Mi <wmi at google.com> wrote:
>
>>>
>>> And does it matter that %vreg29 isn't marked as dead? If so, who should do that marking?
>>
>> The liveness analysis is supposed to do that IIRC. The dead flags are supposed to be properly set otherwise it is considered a bug.
>>
>> Cheers,
>> -Quentin
>
> dead and kill flags are marked by LiveVariables analysis. However I
> find the following paragraph of comment in Passes.cpp:
>
> // 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).
> addPass(&LiveVariablesID, false);
>
> That is why I don't see LiveVariables analysis required after phi
> eliminatation pass. I guess following passes shouldn't depend on
> dead/kill flags but depend on LiveIntervals analysis to get the
> precise interval.
>
> %vreg29 at 528B becomes dead after RegisterCoalescer pass but its live
> interval is not updated accordingly, and RegisterCoalescer declares to
> preserve LiveIntervals. So may be it is RegisterCoalescer to be
> blamed?
Agreed, what I was saying was that I guess it is updated correctly if the kill/dead flags are set properly, which is what we usually test. So again, there are likely several bugs lurking in the regalloc related passes when used in that configuration.
Given how obvious the problem seems to be, I wonder if it is safe to pretend that the coalescer knows how to work without the kill flags.
Anyhow, it looks like the problem we got with Wei’s patch was a side effect of Mikael’s unorthodox configuration of the regalloc. Mikael, could you check if forcing the LiveVariables pass to run fixed the problem when Wei’s patch is in?
Thanks,
-Quentin
>
> Thanks,
> Wei.
More information about the llvm-commits
mailing list