Improved use of vst1 via vec_extract (PR 51819 test case)
ramana.radhakrishnan at linaro.org
Wed Feb 1 23:08:34 UTC 2012
On 1 February 2012 19:33, Ulrich Weigand <Ulrich.Weigand at de.ibm.com> wrote:
> Ramana Radhakrishnan <ramana.radhakrishnan at linaro.org> wrote on 01.02.2012
>> This patch should be queued for 4.8 .Sounds sensible to me.
> OK, thanks for the review!
>> > (As an aside, it might likewise be helpful to update the vec_set
>> > to allow for memory operands, implemented via vld1.)
> The attached patch adds support for vld1 in vec_set as well.
> (See attached file: diff-gcc-arm-vecsetextractmem)
> As a side note, I noticed that the vmov instructions output via
> vec_set and vec_extract use %? to support conditions in ARM mode;
> most of the rest of neon.md doesn't use %?, in particular, the
> patterns where I copied vst1/vld1 from didn't ...
Thanks for following up with that - yes you make a useful small point
here. Neon doesn't support conditionals so you are right the %? is
superfluous there. In theory you can put the neon instructions in IT
blocks but that is deprecated by the architecture and is in general
not recommended. In fact on certain implementations while these
instructions will be supported "architecturally" performance will be
terrible. However because the pattern has a non- "none" neon_type
attribute and is not marked predicable, conditional execution will
never pick this up.
So yes there's no need to perpetuate that.
> What's the issue with this? Should there be %? everywhere, or at
> least used with the vst1/vld1 instructions in vec_set/vec_extract?
>> > B.t.w. I'm wondering how I can properly test:
>> > - that the NEON intrinsics still work
>> The intrinsics tests in gcc.target/arm and gcc.target/arm/neon are the
>> only that we have today that we can run reliably. The other option is
>> the tests from ST but as you've discovered they need the ARM tools.
> Those show no regressions with (either version of) the patch.
I assume by this you mean the intrinsics tests in the testsuite.
>> > - that everything works on big-endian
>> We'll have to put together a big-endian toolchain and test on
>> hardware. qemu doesn't support BE8 mode today and in today's world
>> this is best tested bare-metal on a Fast-Model or on actual hardware
>> both of which will need bring up in terms of dejagnu glue. We're not
>> set up for either today and will probably have to spend some effort in
>> doing this.
> Ah, OK. Maybe another topic for discussion next week ...
Indeed , yes. :) It would be good to include Matt in this discussion
when he's there next week as well.
More information about the linaro-toolchain