Re: [patch]: Add support of new __int128 type for targets having 128-bit integer scalar support

[Kai Tietz <ktietz70 at googlemail dot com>]

2010/5/4 Joseph S. Myers <joseph@codesourcery.com>:
> On Tue, 4 May 2010, Kai Tietz wrote:
>
>> You wrote:
>>
>> 2010/4/30 Joseph S. Myers <joseph@codesourcery.com>:
>> > Should be conditional on __int128 actually being supported. ?That is,
>> > HOST_BITS_PER_WIDE_INT >= 64 and TImode being supported.
>>
>> But for example x86, which has HOST_BITS_PER_WIDE_INT == 32 supports
>> an 128-bit scalar interger (and TImode), when -msse2 is enabled.
>
> No, in that case TImode is essentially an opaque mode; you can't do
> arithmetic on it as GCC can only handle constant arithmetic up to
> 2*HOST_WIDE_INT and it won't build the libgcc functions for TImode
> arithmetic when words are 32 bits. ?Furthermore, 32-bit HOST_WIDE_INT has
> other problems with the code generated being different for different hosts
> and I still maintain (see PR 35466) that we should (a) make all x86
> targets use 64-bit HOST_WIDE_INT, or, preferably, (b) use 64-bit
> HOST_WIDE_INT unconditionally across all hosts and targets to avoid such
> issues.
>
> (The very existence of HOST_WIDE_INT and HOST_WIDEST_INT as types that can
> affect code generation in various ways is one of the messiest parts of
> GCC's internal interfaces and one of the hardest to clean up. ?I think we
> ultimately want a mixture of types whose size depends on the target but
> not the host and not the target configure options, for storing e.g. target
> object sizes, and abstractions that can handle e.g. integers too large for
> the host to process directly but whose semantics do not depend on the size
> of the types internally used to implement them.)
>
>> Additional the 128-bit mode needs to be necessarily TI?

Yes, understood.

> There are no current targets with non-8-bit-bytes. ?If such a target it
> added, the existing
>
> #if HOST_BITS_PER_WIDE_INT >= 64
> ?if (targetm.scalar_mode_supported_p (TImode))
> ? ?...
> #endif
>
> conditionals are one of the many things that will need fixing.

Well, I thought cray is one of those targets with non-8-bit-bytes, but
well, maybe I am wrong here.

Anyway, I adjusted patch in the way you suggested. I changed logic to
initialize int128 type nodes just when HOST_BITS_PER_WIDE_INT >= 64
and TImode is valid. By this logic later just a check for int128-type
!= NULL_TREE can be used. This simplifies logic much.

Patch tested for x86_64-pc-mingw32, i686-pc-mingw32, and x86_64-pc-linux-gnu.

Ok for apply?

Regards,
Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Attachment: int128doc.diff
Description: Binary data