On Fri, 2016-07-22 at 10:17 -0700, James Bottomley wrote: > On Fri, 2016-07-22 at 19:05 +0200, Christian Borntraeger wrote: > > On 07/22/2016 05:59 PM, David Woodhouse wrote: > > > On Fri, 2016-07-22 at 17:52 +0200, Christian Borntraeger wrote: > > > > On 07/22/2016 12:41 PM, David Howells wrote: > > > > > Are there additional things we can get the compiler to do for > > > > > us? Some things I've seen brought up: > > > > > > > > > > (1) Additional __atomic_*() ops could be useful. Suggestions > > > > > I've heard include direct LL/SC support - though the > > > > > compiler people don't seem so keen on that. > > > > > > > > > > (2) -mmodel=kernel flag so that the compiler can optimise > > > > > better for the kernel memory model. > > > > > > > > Some years ago (actually many) Linus proposed to have an > > > > endianess attribute to data types, so that the compiler can do > > > > the bswap automatically. For some reason this was never > > > > implemented, but this might be a good idea anyway. > > > > > > > > e.g. > > > > > > > > unsigned long x[10] __attribute__(("bigendian")); > > > > > > I'm not sure Linus proposed that. I certainly did, many times. > > > > Yes, I know at least 3 people suggesting that and thinking this is > > useful ( Can you beat Linus' 2001 > > https://gcc.gnu.org/ml/gcc/2001-12/msg00932.html? ;-) ) > > The fact that it's been discussed on and off for 15 years tends to > suggest that where we've ended up is about good enough for everyday and > no-one can really be bothered to take the extra effort. > > So what's the overriding reason we should spend the extra effort now? I don't think there's much more to be gained than what I've already done. We *have* the compiler visibility into endianness changes, so it can optimise them correctly. What we *don't* have is the ease of programming, where we can happily *forget* that certain storage is of a specific endianness, do a direct assignment and let the compiler sort it out for us. But that's not actually much use until we can depend on *everyone* having a compiler that supports that. And we have the sparse attributes to catch mistakes where we *forget* the explicit handling anyway, so I don't think there's really much more to be gained. -- dwmw2