[fedora-arm] Fedora 20 for Raspberry Pi????

[Sean Omalley]

On Friday, December 27, 2013 11:27 AM, Gordan Bobic <gordan at bobich.net> wrote:



On 12/27/2013 04:02 PM, Richard W.M. Jones wrote:
>> On Fri, Dec 27, 2013 at 09:53:54AM +0000, Gordan Bobic wrote:
>>> How is transparent alignment fixup going to give you back the
>>> performance you lose from accesses straddling cache lines?
>>
>> You can have structs straddling cache lines and causing performance
>> problems without alignment issues, or structs being packed too close
>> together causing false sharing again w/o alignment being involved.
>>
>> If alignment problems cause performance issues, then we should deal
>> with those performance problems.  If they don't, we shouldn't worry
>> about them.
>>
>> Rich.
>>
>> ObHack: I once worked
with an architecture [68k-based VME hardware]
>> that not only faulted on unaligned access, but also on accesses of the
>> wrong *size* (eg. using a short-sized read instruction instead of a
>> word-sized read instruction).  Dealing with that nonsense involved a
>> lot of compiler-specific massaging of code and some inline assembly ...
>
>I'm very glad you mentioned compilers - this is in fact easily fixable 
>at compiler level. Intel's ICC has an option to make all arrays and 
>structs always aligned to a boundary (up to 16 byte, IIRC). If GCC were 
>to implement such a feature the problem could be made to go away without 
>actually addressing the underlying cause of the problem. It might be a 
>bodge, but since complete fix of the underlying problem isn't going to 
>happen anyway, a good bodge would be a lot better than doing nothing.
>


I agree a good bodge would be better then nothing. It helps a multitude of platforms besides arm,mips, ppc, etc and makes all the platforms run faster (which is why Intel does it in their compiler.). It looks like llvm fixes it as well. 

Here is one of the best articles I have seen written on the subject:
http://www.ibm.com/developerworks/library/pa-dalign/


I am NOT trying to start a compiler war. but.. 
It looks like clang -O3 actually fixes them*. It seems like it would be possible to recompile using clang, and edit clang/llvm to log when it uses fix up code, use that in koji, and automatically file bugs with the log files. (an alternative easy solution for finding them vs adding a bunch of code to gcc which will take some time unless I missed something in gcc.) 

Project safecode (which also uses llvm), actually injects code in, for better reporting of dangling pointers, etc, which could be fed through abrt. But you have to execute the code and hit that section of it. That is probably not a great solution since it starts the compiler war unless it can be done with the llvm optimizer using the gcc dragonegg plugin.  


I haven't looked in a while, are the atomics for armv5/6 supported in gcc or llvm now? 

*(I used http://en.wikipedia.org/wiki/Segmentation_fault#Unaligned_access (Bus Error Example )
with gcc and clang both didn't work, but clang -O3 flag, didn't give a bus error when executed. whether or not it is doing the right thing is another story, but it does mean it is hitting fixup code..maybe gcc has a similar flag I haven't found?)

Sean


Sean