[ARM] 64-bit shifts in NEON.

On 23/02/12 20:36, Andrew Stubbs wrote:
> On 21/02/12 15:23, Andrew Stubbs wrote:
>> On 06/02/12 13:13, Andrew Stubbs wrote:
>>> This patch adds DImode shift support in NEON registers/instructions.
>>>
>>> The patch causes delays any lowering until the split2 pass, after the
>>> register allocator has chosen whether to do the shift in NEON (VFP)
>>> registers, or in core-registers.
>>>
>>> The core-registers case depends on the patch I previously posted here:
>>> http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01472.html
>>>
>>> The NEON right-shifts make life more interesting by using a left-shift
>>> instruction with a negative offset. This means that the amount has to be
>>> negated. Ideally you'd want to do this at expand time, but the delayed
>>> NEON/core decision makes this impossible, so I've chosen to expand this
>>> in the post-reload split pass. Unfortunately, NEON does not provide a
>>> suitable instruction for negating the shift amount, so that ends up
>>> happening in core-registers.
>>>
>>> Another complication is that the NEON shift instructions use a 64-bit
>>> register for the shift amount, but they only pay attention to the bottom
>>> 8 bits. I did experiment with using a DImode shift amount, but that
>>> didn't work out well; there were unnecessary extends and the
>>> core-registers fall back was less efficient.
>>>
>>> Therefore, I've chosen to create a new register class, VFP_LO_REGS_EVEN,
>>> which includes only the 32-bit low-part of the DImode NEON registers so
>>> the shift amount can be loaded into VFP regs without extending them.
>>> This required a new print format 'E' that converts the low-part name to
>>> the full register name the instructions need. Unfortunately, this does
>>> artificially limit the shift amount to the bottom half of the register
>>> set, but hopefully that's not going to be a big problem.
>>>
>>> The register allocator is causing me trouble though. The problem is that
>>> the compiler just refused to use the NEON variant in all of my toy
>>> examples. It turns out to be simply that the IRA & reload passes do not
>>> change hard-registers already present in the RTL (function parameters,
>>> return values, etc.) unless there is absolutely no alternative that
>>> works with that register. I'm not sure if there's anything that can be
>>> done about this, or not. I'm not even sure if it isn't the right choice
>>> much of the time, cost wise.
>>
>> I've now updated the patch to take into account size optimization.
>>
>> Currently, if optimizing for size the compiler prefers to call the
>> libgcc function, rather that do the shift inline.
>>
>> With my old patch, when NEON is enabled it always used the inline code
>> (either in NEON or core-registers) no matter which optimization flags
>> were set. This is more-or-less correct if the register allocator chooses
>> to do the operation in NEON, but much less space efficient otherwise.
>>
>> The update simply disables the core-registers fall-back option when
>> optimizing for size. Transferring the values to NEON registers and back
>> should be roughly the same size as calling a function, so there
>> shouldn't be a big loss.
>>
>> I'm in two minds about the shift-by-constant cases though, since they
>> expand to fewer instructions. Any thoughts?
>
> And yet another update.
>
> This time I noticed that I didn't discard the "clobber"s after the split
> has determined they're not necessary any more. Presumably the
> unallocated "match_scratch"es were harmless, but the unnecessary CC
> clobbers could affect if-conversion and scheduling.
>
> This patch is the same as the previous, except that I've broken out the
> alternatives that don't need any clobbers.
>
> Ok for 4.8?

Ping!

The pre-requisite patch is now committed so this one is ready for review.

Here's a rebased version of the same patch. The only real difference is 
that one of my constraint names is no longer available, so now their all 
renamed.

OK?

Andrew

[ARM] 64-bit shifts in NEON.

Commit Message

Patch