This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: 40 bit integer support
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
joseph@codesourcery.com