Does neon_vset_lane expand wrong code when BYTES_BIG_ENDIAN?

[Xinyu Qi]

Hi,

In neon.md, the define_expand "neon_vset_lane" has extra code to deal 
with the imm operand when BYTE_BIG_ENDIAN,
  unsigned int elt = INTVAL (operands[3]);
  if (BYTES_BIG_ENDIAN)
{
  unsigned int reg_nelts
= 64 / GET_MODE_BITSIZE (GET_MODE_INNER (mode));
  elt ^= reg_nelts - 1;
}

Then,
  emit_insn (gen_vec_set_internal (operands[0], operands[1],
 GEN_INT (1 << elt), operands[2]));


While the define_insn "vec_set_internal" has the extra code as well,
  int elt = ffs ((int) INTVAL (operands[2])) - 1;
  if (BYTES_BIG_ENDIAN)
elt = GET_MODE_NUNITS (mode) - 1 - elt;
  operands[2] = GEN_INT (elt);

It seems these two parts of the code dealing with BYTE_BIG_ENDIAN will cancel 
each other, 
and result in the original imm op unchanged.

Is there something wrong with these code?

Thanks,
Xinyu

RE: Does neon_vset_lane expand wrong code when BYTES_BIG_ENDIAN?

[Xinyu Qi]

From: Joseph Myers [mailto:jos...@codesourcery.com]
> On Wed, 4 Jan 2012, Xinyu Qi wrote:
> 
> > It seems these two parts of the code dealing with BYTE_BIG_ENDIAN will
> > cancel each other, and result in the original imm op unchanged.
> 
> Yes, that's correct.  Lane numbers for NEON intrinsics are the same as
> those used in assembly instructions, but for big-endian they are different
> from those used in the target-independent semantics of the RTL
> intermediate representation.
> 
> > Is there something wrong with these code?
> 
> No, see <http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00409.html> where I
> explain this at greater length.

I see.
Would you mind to take a look at the test case neon-vset_lanes8.c under 
gcc.target/arm/
If BYTE_BIG_ENDIAN, would the x be {1,2,3,4,16,6,7,8} after vset_lane_s8 
(16,x,3) is called?
And if so, it is obviously not equal to y and test fails.

Does this case not suitable for BYTE_BIG_ENDIAN test?

Thanks,
Xinyu

internal compiler error in find_costs_and_classes

[Xinyu Qi]

Hi,

I did some iwmmxt intrinsic test for mainline gcc with this check-in
r190511 | nickc | 2012-08-19 15:11:35 +0800 (Sun, 19 Aug 2012) | 3 lines

PR target/54306
* config/arm/mmintrin.h: Remove spurious #endif.

and encountered an internal compiler error for this simple case, with option 
-march=iwmmxt2 -S
#include
__m64 foo(__m64 r, int i)
{
r = _mm_slli_si64(r, i);
return r;
}
internal compiler error: in find_costs_and_classes, at ira-costs.c:1711

While with -O, compiling could pass.

File a bug?

Tnahks,
Xinyu

Could IWMMXT_GR_REGS be contained by ALL_REGS in ARM back end?

[Xinyu Qi]

Hi,

  Some one point out the root cause for the bug 54338 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54338
is that the IWMMXT_GR_REGS is not contained in ALL_REGS so that an assertion 
fail is triggered in front end.
  I checked the macro REG_CLASS_CONTENTS in arm.h and confirmed it.
  This ICE could be fixed if make ALL_REGS contain IWMMXT_GR_REGS.
  Is there any concerns that IWMMXT_GR_REGS shouldn't be included in ALL_REGS?

Thanks,
Xinyu