[PATCH] ARM: correct liveness on ldm/stm combiner

[Tim Northover]

Hi Renato,

Thanks for the comments. I'll upload a new version to Phabricator.

> Did you check with Matthias about sub-register liveness analysis?

I don't think it will. This pass is run after register-allocation, and
from what I can tell all of his changes take place before.

>>         s1 = VLDRS [r0, 1], Q0<imp-def>
>>         s3 = VLDRS [r0, 2], Q0<imp-use,kill>, Q0<imp-def>
>>         s0 = VLDRS [r0, 0], Q0<imp-use,kill>, Q0<imp-def>
>>         s2 = VLDRS [r0, 4], Q0<imp-use,kill>, Q0<imp-def>
>>
>> we were gathering the {s0, s1} loads below the s3 load. This is fine, but
>> confused the verifier since now the s3 load had Q0<imp-use> with no
>> definition above it.
>
> You mean the order becomes: s3, s1, s0, s2? or s1, s0, s3, s2? The former
> will look broken, the latter, not so much.

The order becomes s3, {s0, s1}, s2. Any reordering of those
instructions would be semantically valid (they're independent loads,
despite the imp-def/imp-use flags), it's just a question of which ones
can actually combine into a VLDM: you need the addresses to be
contiguous in memory and the registers to be consecutive. Only the
{s0, s1} pair satisfies both conditions.

Where we put the load is mostly just a matter of convenience.

>> +define arm_aapcs_vfpcc <4 x float> @foo(float* %ptr) {
>> +; CHECK-LABEL: foo:
>> +; CHECK: vldr s3, [r0, #8]
>> +; CHECK: vldmia r0, {s0, s1}
>> +; CHECK: vldr s2, [r0, #16]
>
> Will it always be in this order? I thought the requirement was to make sure
> it does call a vldmia on {s0, s1} instead of 2 separate loads. In that case,
> a CHECK-DAG would be safer, no?

I believe that if the vldmia ends up at the top then this code-path
won't be exercised, so the order is worth checking. I'll put a comment
in to that effect.

Cheers.

Tim.