After encountering code generation problems for both x86-64 and ARMv6 for some time, I am finally beginning to see the light. The underlying cause I needed to address was that specifying the target triple is not sufficient to define the ABI -- one also needs to specify the CPU type. While the target triple is stored in bytecode files, the CPU type isn't -- it is inferred from the target triple, but this "inferring" is neither well documented, nor leads to a consistent ABI. The resulting issues are difficult to detect, as one needs to examine bytecode or assembler output.
To address this, I have essentially removed all explicit "-target" options in
the kernel library Makefiles, build scripts, and build commands in common.c.
Instead, I now define both HOST_CLANG_FLAGS and HOST_LLC FLAGS that explicitly
choose a set of flags that determine the ABI. For example, on x86-64 I use
llc_host_cpu=$(llc --version | grep 'Host CPU' | sed -e 's/^ *Host CPU: *//')
HOST_CLANG_FLAGS="$HOST_CLANG_FLAGS --target=$host -march=$llc_host_cpu"
HOST_LLC_FLAGS="$HOST_LLC_FLAGS -mtriple=$host -mcpu=$llc_host_cpu"
which seems quite generic. On ARM, I use the slightly more complex
llc_host_cpu=$(llc --version | grep 'Host CPU' | sed -e 's/^ *Host CPU:
*//')
case $host in
*gnueabihf)
case $llc_host_cpu in
arm1176jz-s) llc_host_cpu=arm1176jzf-s;;
esac;;
esac
HOST_CLANG_FLAGS="$HOST_CLANG_FLAGS --target=$host -march=$llc_host_cpu"
HOST_LLC_FLAGS="$HOST_LLC_FLAGS -mtriple=$host -mcpu=$llc_host_cpu"
which also corrects the CPU type that is apparently not auto-detected
correctly. (The missing "f" means that hardware floating point is not
supported, which is inconsistent with the target triple ending in "gnueabihf",
where the "hf" indicates hardware floating point support.)
(As a side note, autoconf's "$host_cpu" corresponds to llvm's notion of
"architecture", not "CPU".)
(On another side note, the clang flags "--target" and "-march" are indeed
equivalent to llc's "-mtriple" and "-mcpu", although the names of these options
indicate otherwise.)
To make things work, I freely used @HOST_* variables everywhere. I see that
pocl makes some effort to use @TARGET_* variables in some places, but this was
not done consistently, so I didn't try a correct solution here. I assume that
the basic idea is that pocl is configured to produce code for HOST as well as
(potentially) one additional device TARGET. While the host properties should be
autodetected, the target properties probably need to be defined manually. I do
not understand where this distinction is made, presumably at run time. Or is
this a configuration time decision? If so, where is the decision made?
-erik
--
Erik Schnetter <[email protected]>
http://www.perimeterinstitute.ca/personal/eschnetter/
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://pgp.mit.edu/.
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________ pocl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pocl-devel
