[Ksummit-discuss] [TECH TOPIC] Compiler shopping list

[Christian Borntraeger]

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? ;-) )


> 
> With the work I put in to make use of __builtin_bswapXX() we do have a
> *certain* amount of the functionality that full endianness attribution
> would give us — the compiler can see and optimise certain
> load/mask/save operations, and can use movbe and equivalent
> instructions.
> 
> But a full implementation that let us just do assignment without
> jumping through the hoops might still be nice.

Absolutely.