Re: [head tinderbox] failure on mips/mips

On Feb 17, 2009, at 10:58 PM, M. Warner Losh wrote:

> In message: <B23797BE-91FB-4AE1-8370-E77D66ED05B6_at_mac.com>
>            Marcel Moolenaar <xcllnt_at_mac.com> writes:
> :
> : On Feb 17, 2009, at 10:42 PM, M. Warner Losh wrote:
> :
> : > : A safer approach is to mark ifi_epoch as packed or put  
> differently,
> : > : define time_t as a 64-bit integral with 32-bit alignment. This  
> can
> : > : avoid a lot of unexpected internal padding as well (e.g. struct
> : > : timeval).
> : >
> : > Marking it as packed won't help.  If the elements aren't properly
> : > aligned, gcc won't access multi-word entities properly.  It might
> : > eliminate the warning, but it will break at runtime.
> :
> : But GCC will use a pair of 32-bit loads and/or stores to
> : access the 64-bit integral in that case. There should be
> : no runtime breakage. You only do this for n32 of course.
>
> Why only n32?  Registers are still 64-bit in n32.

I think that's the problem. With registers still 64-bit, MIPS
n32 isn't really behaving like a 32-bit machine in the case of
64-bit accesses. It's that aspect you want to tweak. So, if
you give all 64-bit integrals an alignment of 4 bytes, then
GCC will use a pair of 32-bit loads and stores (just like,
say, powerpc) and you don't run into the alignment problems
where all of a sudden a data structure gets 8-byte alignment,
triggers warnings, and we try to correct it with kluges.

For MIPS n64 things are like any other LP64 architecture, so
you don't have to tweak anything.

In other words: by tweaking the alignment of 64-bit types in
n32, you prohibit GCC from using the 64-bit capabilities of
the processor and MIPS isn't so weird anymore.

NOTE: On ARM, GCC aligns structures to a 4-byte boundary by
default. This has caused us problems and instead of fixing
the default behaviour of the compiler, we slammed __packed
onto structures. If we had changed the default behaviour of
the compiler, then all structures would be naturally aligned
and we would be able to use the half-word memory accesses
that newer ARM processors have. No, we __packed the lot and
created a big performance bottleneck because now we can only
use byte-wise memory accesses.
What was done for performance (default alignment of 4-bytes
for structures), was turned into a huge pessimisation by us
compensating with __packed. We have more optimal code if
the compiler aligns structures on their natural boundary!

The point being that programmers *do* code with certain
assumptions and as soon as those assumptions don't hold on
a platform, you end up worse off. My thoughts for MIPS n32
are to make it behave like any "normal" 32-bit strong-
alignment platform to avoid 1) a large number of runtime
alignment faults -- which are a bigger performance bottleneck
than forcing 64-bit integrals to be accessed with 2 32-bit
accesses and 2) avoid further abuse of __packed, which turns
all accesses in a series of byte-wise accesses.

At Juniper I changed the ARM compiler default by adding:
	-mstructure-size-boundary=8

That made life a *lot* simpler and performance hasn't been
sacrificed.

Just an explanation of where I'm coming from...

-- 
Marcel Moolenaar
xcllnt_at_mac.com