[LLVMdev] Bi-Endian Compiler

Umesh Kalappa umesh.kalappa0 at gmail.com
Mon Aug 3 00:34:13 PDT 2015


Hi Bergstrom ,

Yes we are targeting on LLVM IR level  and please would you mind share docs .

Thank you
~Umesh

On Thu, Jul 30, 2015 at 11:15 PM, C Bergström <cbergstrom at pathscale.com> wrote:
> On Fri, Jul 31, 2015 at 12:15 AM, Herbie Robinson
> <HerbieRobinson at verizon.net> wrote:
>> I have been quietly working on a port of LLVM to Stratus VOS.  The OS is
>> always big endian (because customers need to migrate data to new hardware
>> quickly and can't afford to convert).  This entails presenting a big endian
>> programming model no matter what the hardware does.  We did this about 15
>> years ago with the Stratus compilers and GCC.  We offered the GCC changes
>> back to the community, but the GCC folks declined to take them...
>>
>> In my copious spare time, I've already written (but not debugged) an LLVM
>> pass that reverses the endianess of the underlying processor.  The LLVM IR
>> is actually quite good for this.  Believe it or not, the hard part is
>> actually dealing with initialization!
>>
>> I am leaving on vacation as soon as my GPS maps get updated; so, I don't
>> have time to read your paper, now.  I will look at it when I get back.
>> Perhaps we can collaborate.  If nothing else, I participated peripherally in
>> the Stratus implementation.  I would like to say a lot more, but I need to
>> hit the road...
>
> We've done this as well.
> http://www.pathscale.com/Bi-ENDIAN
>
> The key piece will be a few things
> 1) Allowing a way to force endian based off an attribute. This can be
> helpful for when you flip the bits, but need to try to triage exactly
> where the problem is
> 2) As other stated - the llvm ir is relatively easy for this - most of
> our changes are on the clang side
> 3) Be *very* careful about patents. There are a number of compiler
> companies that patents around this area.
>
> IANAL and I would not typically say this, but it's something which
> llvm should approach cautiously and probably get advice on before
> accepting patches.
>
> /* I have full docs on what we've done, but it's not public. I can
> share with any interested parties */
>
> Thanks




More information about the llvm-dev mailing list