[Patch, fortran] PR24518 and PR24520 - Improvements to MOD and

[Tim Prince]

Paul Thomas wrote:
> Tim,
> 
>>
>> I wasn't aware of a gfortran real(16) implementation for Itanium. 
>> Supporting that correctly in ia64.md would be a great deal of work.  I 
>> have looked extensively at ia64.md in the past, and there was support 
>> for real(10) but not real(16).
> 
> 
> I was beginning to wonder - is there a real(16) implementation on any 
> system?
> 
>> I'll try to look into the performance question.  If -frename-registers 
>> is not having the intended effect, that would explain ineffectiveness 
>> of other optimizations.
> 
> 
> OK.
> 
>> Sorry for the delay, I'm working from a hotel and from SC05, and just 
>> now got my emailer configuration reconciled.
> 
> 
> That's OK; I have had to get on with other stuff.
> 
> I think that the time has come to resubmit the dot product patch; it 
> never seems to do any harm and can be rather good.  I have removed the 
> condition on the real kind.
> 
> Paul
> 
> 
With my gcc/gfortran installation on Itanium, -frename-registers must be 
specified along with -funroll-loops, in order to avoid loss of 
performance.  I do believe that -frename-registers is desirable only for 
CPUs which lack effective hardware register renaming.

The code generated by a simple sum(a*b) for Itanium does not pipeline. 
It consists of purely serial operations with the same 3 registers 
repeated by the loop unrolling.  So, it will be limited to one addition 
per 4 clock cycles, at best, only 13% of peak floating point 
performance.  I don't think this should influence your decisions about 
implementation of sum() and dot_product().  It's one of the basic 
deficiencies of gnu compilers for this CPU.