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:
>> > 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.
>
> Yes, however TFmode should be __float128 or not?
I am confused. I thought __float128 and "long double" were both going
to be 80-bit IEEE extended in an 128-bit field on x86-64. What you
are saying now makes it sound like __float128 is a different type
altogether (IEEE quad?). If this is so, you'll need to mention TFmode
in your modes.def, but that should be enough.
>> Um? An ADJUST_BYTESIZE for XFmode should automatically update XCmode
>> to match. This works just fine on Itanium.
>
> Looks like I've missed something obvious. This does not appear to be
> happening for me. insn-machmodes.c generated overwrite only
> size/alignment of XFmode depending on runtime setting...
> Can you point for code in genmodes.c responsible for this?
emit_mode_adjustments():
/* Size adjustments must be propagated to all containing modes.
A size adjustment forces us to recalculate the alignment too. */
Do you have the most recent version of genmodes.c?
> What about GET_MODE_BITSIZE? It seems to me that it should be either 128
> or 80, but 96 seems wrong too.
80 is the philosophically correct value, assuming this is IEEE
extended precision we're talking about, but you have to call it 96
bits wide or various things break. (I have to fix these things in
order to deal with ia64's extra special 82-bit extended mode, but
don't hold your breath.)
>> > 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.
>
> For instance for missing signed conversion we used to produce something
> like floatditf, while now we produce floatdixf. So code compiled by
> half with old gcc and half with new will use both.
Right. This is why I needed forwarding stubs.
> Worse yet if we manage TFmode to be 128bit float, one code will
> produce floatditf for DImode to TFmode conversion, while other for
> DImode to 128bit XFmode.
You'll have to rename all the TFmode libcalls to some other
convention. For IA64, it seems sensible to make the HP-UX
convention be used everywhere. Does AMD maybe have a document
defining software float library routines?
zw