[PATCH 1/3] [ARM] PR63870 Add qualifiers for NEON builtins
Alan Lawrence
alan.lawrence@arm.com
Mon Oct 19 16:59:00 GMT 2015
On 14/10/15 23:02, Charles Baylis wrote:
> On 12 October 2015 at 11:58, Alan Lawrence <alan.lawrence@arm.com> wrote:
>
>> Given we are making changes here to how this all works on bigendian, have
>> you tested armeb at all?
>
> I tested on big endian, and it passes, except....
Well, I asked because it seemed good to make sure that the changes/improvements
to how lane-swapping was done, wasn't breaking anything on armeb by the back
door, and so thank you, I'm happy with that as far as your patch is concerned ;).
> for a testsuite issue
> with the *_f16 tests, which fail because they are built without the
> fp16 options on big endian. This is because
> check_effective_target_arm_neon_fp16_ok_nocache gets an ICE when it
> attempts to compile the test program. I think those fp16 intrinsics
> are in your area, do you want to take a look? :)
Heh, yes, I see ;). So I've dug into this a bit, and the problem seems to be
that we don't define a movv4hf pattern, and hence, we fall back to
emit_multi_word_move. This uses subregs, and in simplify_subreg_regno,
REG_CANNOT_CHANGE_MODE_P is true on bigendian (but false on little-endian).
That is, I *think* the right thing to do is just to add a movv4hf (and v8hf)
pattern, I'm testing this now....
Cheers, Alan
More information about the Gcc-patches
mailing list