Richard Biener <richard.guent...@gmail.com> 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) >> >> and >> >> (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. Thanks, Richard
