Re: IA64 TF->XFmode conversion: final

[Jim Wilson <wilson at specifixinc dot com>]

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.

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.

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.

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.  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).

This trick of having bytesize be bitsize plus padding does appear to 
address all of my earlier concerns with using XFmode.  This is a 
solution that never occured to me.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com