Re: IA64 inline division question

[Vladimir Makarov <vmakarov at redhat dot com>]

Steve Ellcey wrote:

> I have been experimenting with doing inlined floating point division on
> IA64 instead of using __divsf3, etc.  The HP compiler does this at all
> optimization levels and it should result in a performance improvement at
> the cost of a slightly larger object size.
>
> Currently when trying to run SPEC with inlined floating point division,
> if I do no optimization I get the correct results, if I combine it with
> -O2 then 177.mesa fails with incorrect results.  I suspect, but am not
> sure, that some incorrect instruction scheduling might be happening.
>
> Currently I am looking at two issues that seem suspicious to me, one is
> that *recip_approx (and *sqrt_approx) are defined as the itanium_class
> fmisc.  I am wondering if this is correct or if they should be fmac
> instead.
I've just looked at this.  It does not matter for Itanium2 (but it is 
different for Itanium1) they have the same reservations, latency times, 
and bypasses.  According to Intel's documentation of Itanium2 it should 
be fmac.  So we could change it to fmac if Itanium1 has no problems. 
Unfortunately I have no available Itanium1, so can not check this.

>  Or perhaps they need their own type.  The other issue is with
> the attribute itanium_requires_unit0.  This treats fmac and fmisc
> differently but I don't see where it is used.  Is itanium_requires_unit0
> obsolete?
>  
It seems obsolete.  Probably that was a part of old insn bundling.  It 
should be removed because it is not used at all.

> I am going to try and create a small test case but in the mean time I
> thought I would see if anyone has any ideas on what the problem might be
> or had any suggestions on what else I should be looking at.
>
>