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

Tim Northover t.p.northover at gmail.com
Fri Aug 31 12:17:26 PDT 2012


Hi,

> It's probably best to revert the VMOVS change. There is also something hinky about the <undef> flags you're setting on the two VEXTD instructions.

Having finally understood (hopefully) what you're saying about the
defs, I've found that the VMOVS patch can be useful (when I was
checking for <imp-use> of the widened source as well it never seemed
to kick in).

Because of that, I'd rather like to fix VMOVS alongside the others
now. Turning to the iffy <undef>s, it looks like in the legal cases
the following logic would apply:

+ Mark source-equivalent D-register <undef> (unless we're lucky enough
to have an <imp-use> on it).
+ Mark dest-equiv D-reg <undef> on first instruction if the original
doesn't have <imp-use>.

> It would be interesting to know if that is good enough to cover the cases you care
> about, or if you will need to compute the liveness of the other lane.

I've run some eyeball tests: VMOVSR *is* still optimised but VMOVS
isn't (it is elsewhere, just not the magical numbers we've decided are
all-important).

Tim.



More information about the llvm-commits mailing list