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

[Tim Northover]

> 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.

Ah, good point. I should have looked more closely at the loop.

And if we don't have to track kill/dead then that solution becomes
more workable. Which leaves us with three options along those lines:
1. A loop before the switch, which stores the removed operands for
later use (they're unknown in number and form so presumably in a
SmallVector of operands).
2. A loop in each case, after saving the bits we need.
3. Unrolled in each case, since we know how many operands there are at
that point. This is identical to the original patches as far as I can
see.

I'm unconvinced of the benefit of 2 over 3 (though laziness may be a
factor there).

> If it's possible to classify the transformations, a table would be a good idea. If each transformation class only has one instance, it's not a big help, of course.

I think, with the examples we've got at the moment (<6, all different
and odd), there isn't enough uniformity to justify a table-based
solution. In Thumb2SizeReduction, we see that even simple rearranging
of registers between instructions disables the optimisation, and we've
only got a handful of cases to spread the cost of abstraction over
here.

Thanks for your help in this, by the way.

Tim.