wide-int, fortran

[Kenneth Zadeck]

On 11/24/2013 05:16 AM, N.M. Maclaren wrote:
> On Nov 23 2013, Andrew Pinski wrote:
>> On Sat, Nov 23, 2013 at 12:16 PM, Steve Kargl
>> <sgk@troutmask.apl.washington.edu> wrote:
>>> On Sat, Nov 23, 2013 at 11:21:21AM -0800, Mike Stump wrote:
>>>>
>>>> Richi has asked the we break the wide-int patch so that the 
>>>> individual port and front end maintainers can review their parts 
>>>> without have to go through the entire patch. This patch covers the 
>>>> fortran front end.
>>>>
>>>> Ok?
>>>>
>>>> +  *logical = wi::eq_p (t, 0) ? 0 : 1;
>>>
>>> I can't find the meaning of :: in n1256.pdf.  What does this do?
>>
>> wi:: eq_p means the function eq_p inside the wi struct.
>
> But you can't tell that from the code - wi might be a namespace, and
> eq_p might be a class.  If there is a clear description of the subset
> of C++ that the front-end is allowed to use, a pointer to it for the
> benefit of Fortran/C/Ada/whatever people would be useful.  But that's
> an aside from this thread.
There is a saying in the US that "you can always tell the pioneers 
because they are the ones with the arrows in their back."   I feel this 
way with respect to C++.   When this branch first went public several 
months ago, the wide-int class made very modest use of C++.   It has 
publicly evolved away from that and i would now describe the usage as 
somewhat aggressive.     I do not know if i think that this is good or 
bad, but i expect that because we are the first big patch to use C++ 
aggressively , that we are going to take some arrows.

>
>>> Also, given the complete lack of a description of what this
>>> patch does and no pointer to a discussion of what this
>>> patch does, and no description of its benefit to gfortran,
>>> I vote "no".
>>
>> The general description was in a different email:
>> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02877.html
>>
>> The main benefit is it allows for targets to support wider integer
>> than two times HOST_WIDE_INT.  So gfortran, is that it connects to the
>> rest of the middle-end of GCC.
>
> Hmm.  Looking at that makes me none the wiser, and even a web search
> doesn't do more than tell me the same aspects.  Given that Fortran has
> somewhat different constraints on type widths than C, it would be very
> useful to know exactly what you mean by that.  C++ is almost entirely
> irrelevant here.
>
A useful way to think about this patch is that it is nothing but 
plumbing.    Gcc has had a painful and long evolution from being a 32 
bit compiler to a 64 bit compiler and beyond.    The primary goal of 
this patch is change the underlying data structures used to represent 
integer constants from being either single host wide ints (that were 
limited to 64 bits) and double-int (that worked reliably for 127 bits 
and mostly ok for 128 bits) to a data structure that would just work 
reliably for any precision integer that a back end supported.

But at both ends of the compiler there are still limits.    It is 
expected that with this patch in place, that a back end maintainer can 
now, for the first time, support architectures that support integers 
wider than 128 bits.  We have several public ports that appear to have 
tried to support some operations on 256 bits but when we tried this on 
our private port, we found an intolerable number of ices and incorrect 
code issues.    They are now gone.

To the extent that this patch touches the front ends, this patch is 
strictly plumbing.   The front ends now use the new wide-int class, or 
the new int-cst to pass integer constants around and do constant prop on 
them.    Beyond that, it is up to the front end maintainers to decide 
how or even if they will expose this to the users of the language.     C 
and C++ currently allow the back end to tell it that they can use wider 
types but actually specifying a large integer constant is at best painful.
> Now, obviously to an implementor, it doesn't mean unlimited-width types,
> but does it (a) allow implementations to use hardware/firmware/emulated
> built-in types however wide they are, (b) allow arbitrary-width types,
> or (c) something else?  In all cases, I can see implementation issues
> in gfortran that do not arise in gcc, but they are different between
> those models.
the patch sniffs the port (in particular, it looks at the extra modes 
specified by the port), and allows integers that are some multiple of 
size of the largest mode specified by the back end. In this way ports 
for small machines pay less of price than the big ports will.

One could imagine that this is not good enough if a front end wanted to 
say that it supports everything up to 256 bits no matter what the 
hardware can do natively, much the way that java said that every host 
had to do 64 bit math, even if it was just a 32 bit host. However, that 
would require a lot more work than was done here. In particular, at some 
level someone would have to sniff the port and break the math into 
pieces that could be implemented on the port.

>
> So I agree that some clarification would be a good idea, to avoid
> introducing secondary problems by accident.  Quite likely there will be
> none, but it's hard to tell.
>
>
> Regards,
> Nick Maclaren.
>
>
>