On Thu, 14 Nov 2013, DJ Delorie wrote: > > That would be one possibility - if the idea is to define __intN for all > > integer modes not matching a standard type (and passing > > targetm.scalar_mode_supported_p), I advise posting details of what effect > > this would have for all targets so we can see how many such types would > > get added. > > I was thinking of using the existing PARTIAL/FRACTIONAL_INT_MODE macros.
FRACTIONAL_INT_MODEs probably work more reliably as integer types than PARTIAL_INT_MODEs, given Bernd's fixes a couple of years ago (I'm not clear on why we actually need both). But I was imagining something that would cover TImode as well, so replacing the existing logic around __int128. > I suspect we'd have to filter out the power-of-two PSI ones though, leaving: I think the filter should be based on being the same number of bits as a standard type (char / short / int / long / long long) rather than being power-of-two. > I'm assuming we need a mode to go with any type we create? Otherwise, Actually, no - bit-fields have funny-sized types that work without their own modes (they should automatically get the next larger integer mode, with padding bits). If you don't have a mode, presumably arithmetic on a larger mode and masking the results is the best way of doing arithmetic on your special type. But this may not be well-optimized (as far as I know the lowering of such operations to use modes the target supports still takes place entirely at RTL expansion time, when it might be better to do it on GIMPLE and let GIMPLE optimizers work on the larger-type arithmetic). If you do want types without corresponding modes, that goes back to having a hook to list the relevant type sizes. -- Joseph S. Myers jos...@codesourcery.com
