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

[Jakob Stoklund Olesen]

On Aug 31, 2012, at 12:17 PM, Tim Northover <t.p.northover at gmail.com> wrote:

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

Sure.

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

That sounds right.

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

If you find that you do need to determine if a lane is live at a given point, it would be nice to have a general-purpose function to do it.

BTW, if you have determined that the other lane isn't live, you can safely use a single vdup instead of two vext instructions.

/jakob