Date: Wed, 18 Feb 2009 10:19:34 -0800 From: Marcel Moolenaar <xcllnt@mac.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips Message-ID: <BE046876-F8EF-4269-9CD6-743483EC1869@mac.com> In-Reply-To: <20090217.235826.-1697751865.imp@bsdimp.com> References: <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> <20090217.234216.1276682135.imp@bsdimp.com> <B23797BE-91FB-4AE1-8370-E77D66ED05B6@mac.com> <20090217.235826.-1697751865.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 17, 2009, at 10:58 PM, M. Warner Losh wrote: > In message: <B23797BE-91FB-4AE1-8370-E77D66ED05B6@mac.com> > Marcel Moolenaar <xcllnt@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@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BE046876-F8EF-4269-9CD6-743483EC1869>