On Fri, 1 Jul 2011, Bernd Schmidt wrote: > On 07/01/11 22:04, Joseph S. Myers wrote: > > I should add: make the type, the new mode, the testcases etc. entirely > > target-specific; target-independent GCC should not need to know or care > > about the specifics of this type. It's bad enough target-independent GCC > > knowing about HImode, SImode, DImode and TImode outside default target > > hook implementations for targets that use those modes. > > The idea here is that there is more than one target that supports 40 bit > operations, so why shouldn't we have support for it in > target-independent code and libgcc? It differs from QI/HI/SImode etc. in > that the precision is known and not target-specific.
Well, the idea of an integer mode with non-target-specific precision is pretty unusual in GCC; normally they are defined as a multiple of QImode (BITS_PER_UNIT). And the existence of this mode is apparently target-specific even if its properties aren't. Apart from the stdint.h code (inappropriate given the lack of a suffix, and where the proliferation of target macros etc. could be avoided once those macros are converted to hooks in some suitable way): * The global tree nodes for various modes are suspicious. Why are they needed at all? * The c_common_type_for_size code using those nodes is suspicious. Front ends shouldn't care about modes like that. Check standard types, otherwise defer to something generic that loops over available types or modes or builds a type as needed. Targets should be able to define integer types and modes as needed - but changing target-independent code for a particular type indicates something is wrong; I wouldn't expect any more target-independent changes than have been associated with floating-point types such as __fp16, __float80 or __float128. There's the odd target hook, and it's necessary to tell libgcc what modes to build for (but in general you have a libgcc function implementation that can be used for more than one mode, depending on the properties of the types, rather than separate implementations per mode). Just as __float80 and __float128 are target-specific types defined by small amounts of target hook code on a couple of targets, I think 40-bit integers should also be like that. > > And is there anything wrong with the existing PDImode name? > > PDImode is so far always defined as MODE_PARTIAL_INT which is handled > quite differently (i.e. by not handling it very much at all). IMO it > would be a bad idea to overload the name. What is the function of having both PARTIAL_INT_MODE and FRACTIONAL_INT_MODE? -- Joseph S. Myers jos...@codesourcery.com
