This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][ARM] PR target/64600 Fix another ICE with -mtune=xscale: properly sign-extend mask during constant splitting


Ping.

Thanks,
Kyrill
On 10/02/15 09:25, Kyrill Tkachov wrote:
Ping.

https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00141.html

Thanks,
Kyrill

On 03/02/15 15:18, Kyrill Tkachov wrote:
Hi all,

The ICE in this PR occurs when -mtune=xscale triggers a particular path
through arm_gen_constant during expand
that creates a 0xfffff00f mask but for a 64-bit HOST_WIDE_INT doesn't
sign extend it into
0xfffffffffffff00f that signifies the required -4081. It leaves it as
0xfffff00f (4294963215) that breaks when
later combine tries to perform an SImode bitwise AND using the wide-int
machinery.

I think the correct approach here is to use trunc_int_for_mode that
correctly sign-extends the constant so
that it is properly represented by a HOST_WIDE_INT for the required mode.

Bootstrapped and tested arm-none-linux-gnueabihf with -mtune=xscale in
BOOT_CFLAGS.

The testcase triggers for -mcpu=xscale and all slowmul targets because
they are the only ones that have the
constant_limit tune parameter set to anything >1 which is required to
follow this particular path through
arm_split_constant. Also, the rtx costs can hide this ICE sometimes.

Ok for trunk?

Thanks,
Kyrill

2015-02-03  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

       PR target/64600
       * config/arm/arm.c (arm_gen_constant, AND case): Call
       trunc_int_for_mode when constructing AND mask.

2015-02-03  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

       PR target/64600
       * gcc.target/arm/pr64600_1.c: New test.





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]