[llvm-commits] [PATCH] Execution domain support for VMOV and VLDR

[Jakob Stoklund Olesen]

On Aug 28, 2012, at 9:00 AM, Tim Northover <t.p.northover at gmail.com> wrote:

> Hi Jakob,
> 
>> BuildMI() just returns a MachineInstrBuilder, and we already have one of those. I don't think it is worth the added complexity in the ExeDepsFix pass to create new instructions.
>> 
>> If you start by stripping off all the explicit operands:
>> 
>>  for (unsigned i = MI->getDesc().getNumOperands(); i; --i)
>>     MI->RemoveOperand(i-1);
> 
> The problem there (that I think Anton was worried about) is that you
> have to restore those operands afterwards: both (some number of)
> implicit registers and the flags associated with normal ones.

Implicit operands always follow the explicit ones, and the loop above only removes the explicit operands. When you add new operands, MI->addOperand() keeps the implicits at the end of the list.

You can simply ignore them.

I am not really comfortable with automatically transferring kills and deads, particularly after you mess around with super-registers.

It is not very important that kill and dead flags are preserved, it is conservatively correct to clear them. It could potentially introduce bugs to add wrong kill and dead flags. If nothing else, the verifier will complain about that.

> It should be generic enough to avoid the fragility Anton's worried
> about, and it would leave ExeDeps unaltered.

I am not sure what Anton was referring to, but I don't think stripping an existing instruction of its operands is any more or less fragile than building a new one.

> Thoughts? It would be good to get a consensus on this (as with
> everything else I suppose), so we can move on.

I agree that the code could use some cleaning up, but I don't think it is necessary to change the interface. I suspect the problem you are trying to solve isn't really a problem at all.

/jakob