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

Tim Northover t.p.northover at gmail.com
Tue Aug 28 09:00:13 PDT 2012


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.

A third approach might be to make setExecutionDomain follow the pattern:

for (each operand) {
  OldOps.push_back(MI->getOperand(i));
  MI->removeOperand(i);
}

switch () {
  case Thing:
    Add relevant operands using OldOps, ignoring def/kill/dead/implicit
}

for (each OldOps) {
  add flags/implicits back
}

It should be generic enough to avoid the fragility Anton's worried
about, and it would leave ExeDeps unaltered. X86 wouldn't change at
the moment, of course. On the other hand that code would then have to
be copied into any backend that uses ExeDeps in a complex way (I'm
thinking particularly of AArch64 here, soon).

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

> It's more important to move these register computations into a function:

Agreed. The patches I have adding new functionality do that, but I
hadn't bothered updating them with the new refactoring until I found
out if it was the right approach. Apparently not.

Tim.



More information about the llvm-commits mailing list