Another problem with "Recommit r265547, and r265610, r265639, r265657"

[Wei Mi via llvm-commits]

On Mon, May 2, 2016 at 4:12 AM, Mikael Holmén
<mikael.holmen at ericsson.com> wrote:
> Hi Wei,
>
> On 04/29/2016 11:26 PM, Wei Mi wrote:
> [...]
>>>
>>> I'm a little concerned about the "0 at x 1 at x" things in %vreg29's range
>>> which
>>> I've no idea if they do any harm and if or how they should be removed.
>>
>>
>> I think they are fine. @x means the VNI is unused. Look at function
>> LiveRange::markValNoForDeletion. It is a lazy way to delete VNIs from
>> valnos.
>
>
> Ok, good!
>
>> The analysis is reasonable and I cannot come up a solution better than
>> yours :-). Although ideally we can have a solution in the end which
>> don't penalize normal cases.
>
>
> Ok!
>
> So, this fix in RegisterCoalescer solves the last problem I ran into.
>
> But the previous problem where we had an instruction with a tied operand...
> How do we solve that?
>
> We've done
>
> @@ -257,0 +258,7 @@ void LiveRangeEdit::eliminateDeadDef(MachineInstr *MI,
> ToShrinkSet &ToShrink) {
> +  // To avoid situations where Def is tied and the same Def/Use registers
> gets
> +  //  new reg ids and we end up with a use of an undefined register (bug
> #10189)
> +  if (MI->isRegTiedToUseOperand(0)) {
> +    DEBUG(dbgs() << "Can't delete, def is tied to operand: " << Idx << '\t'
> << *MI);
> +    return;
> +  }
> +
>
> early in LiveRangeEdit::eliminateDeadDef but I'm not sure if you had a
> better fix for it?
>

Instruction with a tied operand is not triviallyRematerializable so
the problem shouldn't appear either. If that problem still exists with
your patch in RegisterCoalescer, we need to look deeply into what is
wrong there to come up a better fix.

Thanks,
Wei.