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
<s...@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.
