This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ia64 XFmode patch rides again (need ia64-linux testing)


> Jan Hubicka <hubicka@ucw.cz> writes:
> 
> >> 
> >> Having now, I hope, removed all the obstructions, this patch once
> >> again attempts to support simultaneous use of 80-bit and 128-bit
> >> floating point in the ia64 back end.  It's much the same as it was the
> >> last time -- replace TFmode with XFmode in all hardware insns
> >> referring to the extended floating point type; use TFmode exclusively
> >> for software emulated IEEE quad.  However, instead of using
> >> ROUND_TYPE_ALIGN as before, I am using ADJUST_BYTESIZE and
> >> ADJUST_ALIGNMENT declarations in ia64-modes.def, which *should* mean
> >> that everything obeys the requirements.
> >
> > This looks cool.  If I understand it right, to get the same done on
> > x86-64, where we do have 128-bit long doubles in XFmode format and
> > 128-bit __float128, all I need is to define
> > ADJUST_BYTESIZE/ADJUST_ALIGNMENT and kill the TFmode duplicates in
> > i386.md, right?
> 
> I think so.  You will also need to define ADJUST_FLOAT_FORMAT; the
> selected floating point format has to match the byte size.

I played around a bit and in general it appears to work.
(at the moment double test attribute ((mode (TF))) is refused, but I am
interested in getting XFmode long double compatible with old TFmode
first)

I am having problems with XCmodes, as GET_MODE_SIZE==24 and
GET_MODE_UNIT_SIZE==12.  This confuses backend when dealing with complex
numbers in many interesting ways.
Are you using some trick to get this working on Itanium I don't see, or
are we missing feature for adjusting unit_size and re-definition of
size/adjustment/unit_size of XFmode?

Another problem I am having are libcalls.  We used to produce *tf
libcalls and now we do *xf and we expect *tf with different semantics.
I see that you are renaming the TFmode builtins into HP-UX compatible
names, I can do similar trick, but that solves just half of problem.  If
we link old code with newlibgcc or vice versa the libcalls won't
match...

Honza
> 
> zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]