IA64 TF->XFmode conversion: final

[Zack Weinberg]

Jim Wilson <wilson@specifixinc.com> writes:

> Zack Weinberg wrote:
>> Here is the final version of the patch to convert ia64.md from TFmode
>> to XFmode for 80-bit extended floating point, and therefore to enable
>> simultaneous use of 80-bit extended and 128-bit IEEE quad float in the
>> same code.  (GCC does not currently have an emulation library for IEEE
>> quad float.)
>
> I am only now able to look at this, and I see it is finished
> already. Oh well.  I didn't look at this last week because ia64-linux
> didn't bootstrap due to a bug in one of Jan's cgraph patches, and I
> wanted to get that fixed first.  I am looking at this now, and will
> let you know if I find problems in testing.  Hopefully bootstrapping
> isn't broken again.  I do have some initial comments on the patch
> though.

Sorry about that.  I have a mess of other patches that were blocked on
that one, and I was satisfied with my own testing on ia64-linux.

> You added new macros ADJUST_BYTESIZE and ADJUST_ALIGNMENT as part of
> an earlier patch, but you didn't add documentation for them.
>
> There are also a bunch of other new undocumented macros not used by
> the IA-64 port: RESET_FLOAT_FORMAT, CC_MODE, FLOAT_MODE,
> PARTIAL_INT_MODE, INT_MODE.  This whole target dependent mode scheme
> is undocumented.

The documentation is in machmode.def.  I no longer make substantial
additions to manuals under the GFDL.

I plan to add a lot more commentary to genmodes.c as soon as I get out
from under the pile of deadlines.

> Your ADJUST_BYTESIZE macro makes it possible to have a port where a
> mode bitsize is not its byte size times BITS_PER_UNIT.  This is
> surprising, and yet you don't seem to have documented it anywhere.
> Since this is a signficant change, it probably should be documented.
> Since the IA-64 port is the only port using this trick, this has the
> potential to make the IA-64 port less stable if others aren't aware of
> it.

Note that this was already the case for BImode, and that other ports
can usefully make use of it (e.g. x86-64).

I think the text in machmode.def is clear enough: e.g.

     FRACTIONAL_FLOAT_MODE (MODE, BITSIZE, BYTESIZE, FORMAT);
        declares MODE to be of class FLOAT, BYTESIZE bytes wide in
        storage, but with only BITSIZE significant bits, using
        floating point format FORMAT.

It's not just ADJUST_BYTESIZE that does this -- it happens that no one
is presently using the FRACTIONAL_{FLOAT,INT}_MODE macros, but the
intent is e.g. to have IEEE extended be defined by

  FRACTIONAL_FLOAT_MODE (XF, 80, bytesize, format);

whenever possible.  [It is not currently possible to use 80 for the
bitsize/precision of IEEE extended, for unrelated reasons which I plan
to address Real Soon Now.]

> The distinction between the byte size and bit size seems to be roughly
> the same distinction we make between TYPE_SIZE and TYPE_PRECISION,
> which makes sense.

In fact I got the idea from TYPE_PRECISION.

> Changing the macro name GET_MODE_BITSIZE to GET_MODE_PRECISION might
> make sense to clarify this, but would be a rather large patch.  If
> we don't change the macro name though, I'm afraid we will have
> continuing problems with people confusing GET_MODE_SIZE and
> GET_MODE_PRECISION (aka GET_MODE_BITSIZE).

I'm willing to do such a patch if it's not considered to be too big a
change for 3.4.  It should be just search and replace.

zw