This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RS6000] num_insns_constant ICE
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Alan Modra <amodra at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 30 Nov 2018 18:49:02 -0600
- Subject: Re: [RS6000] num_insns_constant ICE
- References: <20181125121912.GO21617@bubble.grove.modra.org> <20181129195233.GF23873@gate.crashing.org> <20181130074639.GK22912@bubble.grove.modra.org>
On Fri, Nov 30, 2018 at 06:16:40PM +1030, Alan Modra wrote:
> On Thu, Nov 29, 2018 at 01:52:34PM -0600, Segher Boessenkool wrote:
> > On Sun, Nov 25, 2018 at 10:49:12PM +1030, Alan Modra wrote:
> > > + while (nregs-- > 0)
> > > + {
> > > + int ins = num_insns_constant_gpr (value);
> >
> > You probably should mask "value" here so that it is only one GPR.
> > Alternatively, make num_insns_constant_gpr handle that. Consider what
> > happens for a 64-bit number with 32-bit registers here?
>
> Oh, right, the low part will always give an answer of 2 if the high
> parts isn't merely a sign extension.
>
> > > + val = l[WORDS_BIG_ENDIAN ? 0 : 1] << 32;
> >
> > This doesn't work, as in the other patch: long can be 32 bit.
>
> Huh, I originally had "high" and "low" HOST_WIDE_INTs which avoided
> this sort of problem on 32-bit hosts.
>
> Revised patch follows. Bootstrapped and regression tested
> powerpc64le-linux. Hopefully this has removed all the stupidity.
I think it is fine like this, or certainly an improvement :-) Okay for
trunk. Thanks!
Segher
> * config/rs6000/rs6000.c (num_insns_constant_gpr): Renamed from
> num_insns_constant_wide. Make static. Revise comment.
> (num_insns_constant_multi): New function.
> (num_insns_constant): Formatting. Correct CONST_WIDE_INT
> calculation. Simplify and extract code common to both
> CONST_INT and CONST_DOUBLE. Add gcc_unreachable for unhandled
> const_double modes.
> * config/rs6000/rs6000-protos.h (num_insns_const_wide): Delete.