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: Using gen_int_mode instead of GEN_INT minot testsuite fallout on MIPS


On Thu, Sep 12, 2013 at 6:19 PM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> Richard Biener <richard.guenther@gmail.com> writes:
>> On Wed, Sep 11, 2013 at 8:39 PM, Richard Sandiford
>> <rdsandiford@googlemail.com> wrote:
>>> Graham Stott <graham.stott@btinternet.com> writes:
>>>> Hi Richard,
>>>>
>>>> There is some minor testsuite fallout with these patches on MIPS a
>>>> couple of tests (see below)ICE ingen_int_mode () in both these ICE the
>>>> mode is CCmode.
>>>
>>> Hmm, interesting.  I suppose gen_int_mode should handle CC modes,
>>> since there's no other constant rtx that can be used instead.  OTOH,
>>> like you say, it doesn't really make sense to apply try_const_anchor
>>> to CCmode.
>>
>> Can we statically identify the places that build CCmode integers?  In that
>> case a gen_cc_const () function would be more appropriate ...
>
> I think it'd be hard to do statically.  E.g. it wasn't really obvious
> that this particular cse code might have to handle CCmode.
>
> It might be better to have a different rtx for MODE_CC constants,
> hopefully then just using gen_rtx_CONST_CC (...) directly.
> It'd be a lot of work though.
>
>> Do we know that CCmode fits into a HWI btw?
>
> The precision of CCmode is effectively left undefined, so it's hard to say.
> But it always seems to have worked in practice.
>
> I suppose the most likely values are 0, 1 and -1, although MIPS did for
> a while have 1.0f as the CC value for "true".
>
>> (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)

Richard.

> Thanks,
> Richard


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