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

[Jan Hubicka <hubicka at ucw dot cz>]

> 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

__float128 is supposed to be IEEE quad.  long double is supposed to be
80-bit IEEE in 128-bit.
> 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?

So the sollution really is easy :)  I didn't updated since yesterday.

> Right.  This is why I needed forwarding stubs.
> 

So the right sollution would be to provide both *xf *tf with the same
semnatics + TFmode libcalls under new names...

> > 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?
No, but we can write one.
Any particular prefferences in convention?  Or taking the HP-UX names
you do use would be OK?

Thanks,  I will try with updated tree tomorrow :)

Honza
> 
> zw