Re: powerpc & unaligned block moves with fp registers

Re: powerpc & unaligned block moves with fp registers

[degger]

On 11 Nov, mike stump wrote:

> And next, tell us what the performance would be if 98.3% of all
> dynamic loads were aligned just right, and the remainder were not in a
> typical large application, and the same stat for a smallish
> application?

This cries for some heuristics which decides that some structure is
likely to be accessed more often and thus possible more critical
to performance due to many accesses.
 
> If the size decrease improves the instruction cache, and most of the
> dynamic cases run fast anyway, would it not be possible for the code
> to be actually slow if we followed your recommendation, even in the
> non -Os case?  If not, why not?

This is not an easy decision and for sure one I wouldn't want to enforce
globally for the whole compiler. Also the amount of effect depends very
much on the complete system; the CPU, the amount of memory and cache and
even the operation mode of the CPU. Maybe it would be possible to
implement some feedback optimisation that doesn't just instrument the
iteration count of some codeblock but also the effect on the current
CPU including the cachemisses. Of course is not a good general approach
but would be a start to tell the compiler "optimize the software for a
machine close or equal to this one".
 
> Also, what is the typical non-aligned hit rate in a large suit of
> benchmarks?  1.7%, lower, higher?

No idea, I'll leave that up to the benchmark guys.
 
> Anyway...  I ask all there questions, to try and help ensure that as
> we make changes in this area, that we don't just make them blindly (in
> the absence of real benchmarking data).

Yes, this looks like a sane idea and I appreciate your efforts to keep 
me away from dreaming of an ideal world. :)

--
Servus,
       Daniel

Re: powerpc & unaligned block moves with fp registers

[David Edelsohn]

>>>>> mike stump writes:

mike> Anyway...  I ask all there questions, to try and help ensure that as
mike> we make changes in this area, that we don't just make them blindly (in
mike> the absence of real benchmarking data).

	FYI, IBM performs these types of benchmarks on its compilers and I
am applying those deduced heuristics to the PowerPC backend of GCC.
However, those heuristics only are effective if the common part of the
backend uses machine description hooks instead of applying its own,
generic heuristics.

David

Re: powerpc & unaligned block moves with fp registers

[Robert Dewar]

> I would have to be shown that there is existing code that expects 
> volatile
> accesses to misaligned doubles to be atomic.

I would certaqinly agre that this expectation is highly dubious.

Re: powerpc & unaligned block moves with fp registers

[Robert Dewar]

> I agree with this, actually, but the group seems to be moving more in 
> the
> direction of not supporting anything nonstandard (strict aliasing, which
> broke lots of existing code including gcc itself, springs to mind).


A couple of points here.

First the standard is a means to an end, not an end in itself. The end is to 
provide a useful compiler. A compiler that meets the standard but is not
useful is a dubious artifact. So arguing from the standard is always a
tricky business. Certainly we don't want to do seriously inefficient
things to accomodate "bad" code, but we have to be careful to make sure
that we are talking about serious inefficiency.

Compiler writers always tend to be too optimistic about the benefits of
particular optimizations.

For example, strict aliasing, just how important is this. As compiler
writers, we would tend to believe it was critical, but do we really have
data that supports this. The only measurement we did in Ada was on the
compiler itself. GNAT runs 1% slower if compiled with no strict aliasing.
Since strict aliasing results in a number of unexpected behaviors in
Ada code (all cases where the standard does not require the expected 
behavior, but this does not chnage the expectations :-)

Richard reacts that the compiler is non-typical (our discussion was about
whether strict aliasing should be the default in GNAT). Fine, I am willing
to believe that is the case, but still it would be nice to have some real
customer programs that show the supposed huge benefits of strict aliasing!

Re: powerpc & unaligned block moves with fp registers

[Dale Johannesen]

On Saturday, November 1, 2003, at 04:21  AM, Robert Dewar wrote:

>> We should be very careful to not remove `working' and reasonable
>> semantics that are widely implemented and depended on by existing 
>> code,
>> just because some standard can be read in such a way that suggest that
>> something might not be mandated to work.

I agree with this, actually, but the group seems to be moving more in 
the
direction of not supporting anything nonstandard (strict aliasing, which
broke lots of existing code including gcc itself, springs to mind).

> I would think that many C programs assume that access to a volatile 
> variable
> is in fact atomic if the machine can easily generate instructions to 
> make
> it so, given that standard C lacks a mechanism for specifying atomic 
> access,
> so I would agree with Mike that you want to be careful here on making 
> changes.

I would have to be shown that there is existing code that expects 
volatile
accesses to misaligned doubles to be atomic.  This doesn't even work in
many environments.

Re: powerpc & unaligned block moves with fp registers

[Robert Dewar]

> We should be very careful to not remove `working' and reasonable 
> semantics that are widely implemented and depended on by existing code, 
> just because some standard can be read in such a way that suggest that 
> something might not be mandated to work.

I would think that many C programs assume that access to a volatile variable
is in fact atomic if the machine can easily generate instructions to make
it so, given that standard C lacks a mechanism for specifying atomic access,
so I would agree with Mike that you want to be careful here on making changes.

Re: powerpc & unaligned block moves with fp registers

[Mike Stump]

On Friday, October 31, 2003, at 02:45  PM, Dale Johannesen wrote:
> On Friday, October 31, 2003, at 07:47  AM, David Edelsohn wrote:
>> 1. Do we *ever* want to use fp regs for unaligned mem-mem moves?  Is
>>    there any 32-bit PPC chip where an unaligned 64-bit fp move is
>>    faster than two (maybe unaligned, maybe mot) 32-bit moves?
>>
>> 	What about volatile?
>
> I don't believe 'volatile' requires atomic accesses.  You can have 
> objects of
> volatile-qualified struct types, and can copy them.

We should be very careful to not remove `working' and reasonable 
semantics that are widely implemented and depended on by existing code, 
just because some standard can be read in such a way that suggest that 
something might not be mandated to work.

Re: powerpc & unaligned block moves with fp registers

[David Edelsohn]

1. Do we *ever* want to use fp regs for unaligned mem-mem moves?  Is
   there any 32-bit PPC chip where an unaligned 64-bit fp move is
   faster than two (maybe unaligned, maybe mot) 32-bit moves?

	What about volatile?

David

Re: powerpc & unaligned block moves with fp registers

[degger]

On 11 Nov, David Edelsohn wrote:

>> Depends on the CPU, The latest PPCs for example combine
>> accesses under most conditions, however having several
>> accesses instead of a single one will lead to higher I-Cache
>> pressure. I would prefer aligning the complete structure on a
>> natural boundary and extract single components by masking
>> them.

> 	Aligning the structure on particular boundaries violates the
> existing PowerPC ABIs.  Next...

So the linker is not free to choose where to put the structures in
memory? Dang, I haven't thought about this I have to admit. At least we
could issue a warning telling the developper to reconsider the structure
entries to get a better alignment.

--
Servus,
       Daniel 

Re: powerpc & unaligned block moves with fp registers

[David Edelsohn]

>>>>> degger  writes:

Daniel> Depends on the CPU, The latest PPCs for example combine accesses under
Daniel> most conditions, however having several accesses instead of a single one
Daniel> will lead to higher I-Cache pressure. I would prefer aligning the
Daniel> complete structure on a natural boundary and extract single components
Daniel> by masking them.

	Aligning the structure on particular boundaries violates the
existing PowerPC ABIs.  Next...

David

Re: powerpc & unaligned block moves with fp registers

[degger]

On 10 Nov, dewar@gnat.com wrote:

> Sure, of course, no one disputes that. The real issue is to find out
> whether unaligned accesses are better/same/worse as multiple accesses
> with combining of resuls.

Depends on the CPU, The latest PPCs for example combine accesses under
most conditions, however having several accesses instead of a single one
will lead to higher I-Cache pressure. I would prefer aligning the
complete structure on a natural boundary and extract single components
by masking them.

--
Servus,
       Daniel