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:12:36 +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>
On Fri, Sep 13, 2013 at 10:08 AM, Richard Sandiford
> Richard Biener <firstname.lastname@example.org> writes:
>>>> (what about partial integer modes which have weird precision (none)?)
>>> We don't really model that properly yet. Partial modes are just defined
>>> using something like:
>>> PARTIAL_INT_MODE (SI);
>>> i.e. without the partial precision. But trunc_int_for_mode is based on
>>> GET_MODE_PRECISION, so should just work if a proper precision is added.
>>> (There are other places that wouldn't just work, but that's something
>>> that the wide-int branch will help with. It almost feels like you were
>>> setting me up for that answer. :-))
>> Well I was asking because if you change a GEN_INT (x) to
>> gen_int_mode (PSImode, x) then you'll end up in trunc_int_for_mode with
>> PSImode which looks at GET_MODE_PRECISION (PSImode is still
>> a SCALAR_INT_MODE_P ...). We set precision of PSImode to -1U
>> it seems, but that still means that the constant is not even canonicalized
>> to the underlying mode. (so, should we set partial integer modes precision
>> to the precision of the base mode? Well, of course we should simply set
>> an appropriate precision at mode definition time)
> 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).