This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: ia64 XFmode patch rides again (need ia64-linux testing)
Jan Hubicka <hubicka@ucw.cz> writes:
>> > 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)
A mechanism for handling attribute ((mode (foo))) where foo is not a
known machine mode would also be useful in the context of vectors. We
ought to be able to list in the modes.def only those vectors supported
directly by hardware.
> 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?
Um? An ADJUST_BYTESIZE for XFmode should automatically update XCmode
to match. This works just fine on Itanium.
What were you expecting GET_MODE_SIZE and GET_MODE_UNIT_SIZE to be?
> 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...
I am not sure I understand the problem.
zw