This is the mail archive of the
mailing list for the GCC project.
Re: Using gen_int_mode instead of GEN_INT minot testsuite fallout on MIPS
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, Graham Stott <graham dot stott at btinternet dot com>, James Greenhalgh <james dot greenhalgh at arm dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Richard Sandiford <rdsandiford at googlemail dot com>
- Date: Fri, 13 Sep 2013 10:43:39 +0200
- Subject: Re: Using gen_int_mode instead of GEN_INT minot testsuite fallout on MIPS
- Authentication-results: sourceware.org; auth=none
- References: <CAFiYyc3o+GLpPnNb=E1ru9rOJxuVkxBMsMEeE99wRm8SRWrmCg at mail dot gmail dot com> <1378833157-11511-1-git-send-email-james dot greenhalgh at arm dot com> <87y574mr2h dot fsf at talisman dot default> <1378900963 dot 71148 dot YahooMailNeo at web87402 dot mail dot ir2 dot yahoo dot com> <87y573kxse dot fsf at talisman dot default> <CAFiYyc1aR91hKgkGMbLfVtH0vmXOBPruaiPRqQ5-FCA5gTDMWg at mail dot gmail dot com> <87ppseko71 dot fsf at talisman dot default> <CAFiYyc36vmFX0HneNXQFcBT5ajGZ2fapVCX08DBR-x+LY7h1mQ at mail dot gmail dot com> <87d2odkuu7 dot fsf at talisman dot default> <CAFiYyc1F1TPrYeQzTW7Z7PSgYTRnzfuFj5R+dVW4ONAdp2nnvA at mail dot gmail dot com> <877geli0ij dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com>
On Fri, Sep 13, 2013 at 10:33 AM, Richard Sandiford
> Richard Biener <firstname.lastname@example.org> writes:
>>> Yeah. I don't think it makes sense to canonise PSI to 32 bits when we
>>> know it has fewer than 32 bits. It's still going to be wrong, and will
>>> still defeat one of the main purposes of canonical constants, which is
>>> to make equality obvious. E.g. we'd still treat PSI constants
>>> (const_int 0x...ff80000000)
>>> (const_int 0x...ffc0000000)
>>> as different, even though they're both zero for a 24-bit PSI.
>>> This partial integer mode stuff is just a big hack. Like you say,
>>> we can only really do something sensible if we know what the real
>>> precision is.
>>> So I'd rather leave things as they are for this series. The precision
>>> effectively becomes 65535 thanks to the underlying unsigned short array,
>>> so like you say, trunc_int_for_mode is a no-op for partial modes.
>>> Changing GEN_INT to gen_int_mode shouldn't make any difference.
>>> What do you think about the patch for CC modes?
>> I wonder if we can do without changing gen_int_mode by fixing the callers
>> like you did for cse.c (that patch is ok).
> But the point of the gen_int_mode patch is that (for better or worse)
> CONST_INT is the right choice of rtx for constant CC values. I'd like
> eventually to get rid of all GEN_INT callers, and some of those callers
> will sometimes or always be handling CC modes. This would then crop up
> again in a legitimate context.
> IMO, cse.c was buggy not because it was trying to generate a CCmode
> CONST_INT, but because anchor optimisations involve addition, which
> isn't defined for CC modes.
> I think gen_int_mode should do the right thing for all CONST_INT modes.
> gen_int_mode (X, MODE) should really be the moral equivalent of
> gen_rtx_CONST_INT (MODE, X), despite the confusingly-swapped parameters.
Yeah, ok. But the GEN_INT changes have already uncovered quite some bugs
so maybe let us discover a few more CCmode bugs first? ...
Anyway, as you choose - the patch is ok in the end.