Den Wed, 28 Aug 2013 21:29:02 -0400 skrev [pocl-devel] ARM (or LLVM?) Woes:
> I have spent the past week or so making pocl build on ARMv6, i.e. a > Raspberry Pi. The basic problem I encountered is the following: hehe :) > Some people call this the "hardware floating point problem", although > this is something of a misnomer. Trying to support hardware floating > point operations triggers this problem, but the problem is not > intrinsically about hardware floating point operations. Just so. The hard-float seems to be the first place where this issue becomes painfully obvious. I.e. stuff breaks due to the ABI change. > On ARM, different CPU types offer vastly different features. For > performance reasons, ARM offers several incompatible ABIs. > Unfortunately, the target triple does not choose the ABI! The reason > is somewhat indirect -- although the ABI is actually specified in the > target triple, llvm will ignore this (!) unless one also specifies a > CPU type that has sufficient features to use this ABI. Otherwise, > llvm will generate code for a "basic" CPU, which may lack features, > and will then (silently!) switch over to a different ABI. I would > consider this a design bug in llvm, but that's what we have. Looking at lib/Driver/ToolChains.cpp, there are only 4 target triples that clang recognizes. I guess all the rest go the ARMv4-gnueabi way. > I think the following is necessary for pocl: When configuring a > target, we should not look for a target triple, but should rather > accept a set of options that may include CPU type, FPU type, ABI > specification, and architecture attributes as well. This would likely > also improve performance on other architectures, such as x86_64. We > may need to ask for this information twice, since clang and llc > expect it in different form, but maybe we can also translate this > ourselves. Yes, this needs to be done. But it probably requires extensive re-writes of the configure.ac and some extra platform detection code. And now is actually a good moment to consider ditching the script-based approach, if we are going to use the LLVM API way of interfacing with LLVM soon. Otherwise we might come up with a solution that needs re-write soon again. Unfortunately, the current state of the API way is quite immature still. Of course, the scripts are a much nicer way of trying things out... What are your opinions on this? > Of course, at the moment, configuring host and target is a bit of a > mess, and it's not clear which configuration (environment) variable > is used under what circumstances; a bit of clean up here would help. Oh quite. A patchwork quilt of kludges is the kindest description of satus quo I can come up with. And I should know - made most of this mess :) kalle ------------------------------------------------------------------------------ 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=58040911&iu=/4140/ostg.clktrk _______________________________________________ pocl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pocl-devel
