Richard Biener <richard.guent...@gmail.com> writes: > On Wed, Sep 11, 2013 at 8:39 PM, Richard Sandiford > <rdsandif...@googlemail.com> wrote: >> Graham Stott <graham.st...@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. :-)) Thanks, Richard
