Re: __int256

[Mike Stump <mikestump at comcast dot net>]

On Jul 13, 2012, at 6:39 AM, Joseph S. Myers wrote:
> On Fri, 13 Jul 2012, Mike Stump wrote:
> 
>> As I said, in Kenny's next patch, we add support for all constants of 
>> any size the port needs.  I don't know if you've ever tried to use the 
>> compiler with OImode, but, what I can say is the bugs are not terribly 
>> latent at times and they are not hidden very well at all, today.  The 
>> goal of course, is to improve that and make it work better.  These 
>> issues that I know about existed, prior to my patch, and we are in the 
>> process of fixing them.  Some have been fixed, others remain to be 
>> fixed.  The issues I'm thinking about exist with or without my patch to 
>> the frontend to support __int256.  Merely adding __int256 doesn't make 
>> any of the issues I'm aware of appear, and the issues I'm aware of don't 
>> appear with sizes less than 256.
> 
> I think the patches allowing constants of such a type to work should go in 
> first,

I understand the beauty of putting in the const wide int stuff first...  I don't think it matters much to me...  but I might ask why?  I think we have added support for all in-tree gcc ports for all possible testcases.  Do you know of a single testcase that fails on a single port?

> and the libgcc support,


I wanted to separate the patches and keep them in small well focused review groups, as they hit wildly different reviewers.

> before we consider the support for the type from the front ends using keywords as opposed to mode attributes.

I believe that libgcc support for all existing in-tree ports of gcc is already complete.  We'd be happy to do any libgcc work necessary to make any testcase work on any existing in-tree gcc port.  If you know of any work that remains to be done, please provide a testcase, and I can ensure the work is complete.

> You're using OImode in target-independent code.

> But I don't see a change to machmode.def to add it as a machine-independent mode.

Ah, good catch.  I've moved OImode up from the ports in the patch below.

> Nor do I think
> it *should* be a machine-independent mode; it's sufficiently specialised 
> that it should be possible to do things without it needing to be one.

Hum, how about this, if you fix __int128 to do it the way you want, then I will fix __int256 to copy the style that is set by __int128.  I'd rather have them be exactly the same, so that testing for one will more likely help the other one.  I don't have a good idea of a better way to do this.  Longer term, I'd like __int256 to be universally available, just like long is and just like long long is.  We can't do that yet, I think doing that is premature.

> See my comments (several messages on 1 July 2011) about 40-bit integer 
> support;

Ick, 40 / 8 is 5, and 5 isn't a power of 2, therefore, they are different cases to me.	  I appreciate that you'd like to see HImode go, wake me up when that is done.

> carefully designed target hooks to specify the keywords / modes 
> for target-specific integer types are better than adding more and more 
> cases to several difference places in the target-independent compiler.

Agreed, on general principals.  And, if I waned 60 bit support, or 250 bit support, I'm right there with you.  However, 32 support, has, over time, proven to be the right answer.  Likewise, merely shifted by some years later, 64 bit support.  While 128 and 256 may seem to you to be as odd now as 64 bit support was back when 8 was all the rage...  well, I'll stop there.  Let me just say, these are special because they are powers of 2.

If you can sketch out a better incantation for the 128 and 256 bit support, I can try my hand at improving it.  I just don't know any better form for it.  I'd argue that all powers of twos in use by any port, should be put into machmode.def.  I can rip out all TImode handling, leaving the int128 handling, the TImode code I think is redundant with the int128 code.  Would you like me to do that?  I just don't want to be on the hook when it doesn't work out for someone.

> __int128_t and __uint128_t are legacy built-in typedef names and I don't 
> think there should be any analogue for 256-bit integers; just __int256 and 
> unsigned __int256.

Ok, fixed.

>> I have put the patch through the C test suite, and it doesn't show any 
>> failures.
> 
> Certainly you should add analogues of 
> gcc.dg/torture/fp-int-convert-*timode.c for the new type and verify that 
> those tests all work for it.  It would seem advisable to add tests 
> covering pure integer operations for the new type (all the C integer 
> operations), for both constants and runtime evaluation, as well.

Ok, fixed.  I put in the portable testcase, esoteric things like 80 bit floating point numbers can be added by people that like such things.

Attachment: int256-1.diffs.txt
Description: Text document