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.
Yes, however TFmode should be __float128 or not?
> > 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.
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?
>
> What were you expecting GET_MODE_SIZE and GET_MODE_UNIT_SIZE to be?
32 and 16 respectivly (I adjust BYTESIZE of XFmode to 16bytes)
What about GET_MODE_BITSIZE? It seems to me that it should be either 128
or 80, but 96 seems wrong too.
>
> > 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.
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.
Honza
>
> zw