HEADS UP: sparc64 backend for llvm/clang imported
jmg at funkthat.com
Sat Mar 1 01:16:50 UTC 2014
Dimitry Andric wrote this message on Fri, Feb 28, 2014 at 20:22 +0100:
> In r262613 I have merged the clang-sparc64 branch back to head. This
> imports an updated sparc64 backend for llvm and clang, allowing clang to
> bootstrap itself on sparc64, and to completely build world. To be able
> to build the GENERIC kernel, there is still one patch to be finalized,
> see below.
> If you have any sparc64 hardware, and are not afraid to encounter rough
> edges, please try out building and running your system with clang. To
> do so, update to at least r262613, and enable the following options in
> e.g. src.conf, or in your build environment:
> WITH_LIBCPLUSPLUS=y (optional)
> Alternatively, if you would rather keep gcc as /usr/bin/cc for the
> moment, build world using just WITH_CLANG, enabling clang to be built
> (by gcc) and installed. After installworld, you can then set CC=clang,
> CXX=clang++ and CPP=clang-cpp for building another world.
> For building the sparc64 kernel, there is one open issue left, which is
> that sys/sparc64/include/pcpu.h uses global register variables, and this
> is not supported by clang. A preliminary patch for this is attached,
> but it may or may not blow up your system, please beware!
> The patch changes the pcpu and curpcb global register variables into
> inline functions, similar to what is done on other architectures.
> However, the current approach is not optimal, and the emitted code is
> slightly different from what gcc outputs. Any improvements to this
> patch are greatly appreciated!
> Last but not least, thanks go out to Roman Divacky for his work with
> llvm/clang upstream in getting the sparc64 backend into shape.
Ok, I have a new pcpu patch to try. I have only compile tested it.
It is available here:
I've also attached it.
Craig, do you mind testing it?
This patch also removes curpcb as it appears to not be used by any
sparc64 C code. A GENERIC kernel compiles fine, and fxr only turns up
curpcb used in machdep code, and no references to it under sparc64.
This is not a proper solution in that
it can mean counters/stats can be copied/moved to other cpus overwriting
the previous values if a race happens... We use
PCPU_SET(mem, PCPU_GET(mem) + val) for PCPU_ADD, not great, but it's
no worse than what we were previously using..
Until we get a proper fix which involves mapping all the cpu's PCPU
data on all CPUs, this will have to sufice..
This patch is based upon, I believe, a patch from Marius and possibly
modified by rdivacky.
Thanks for testing..
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3274 bytes
Desc: not available
More information about the freebsd-sparc64