Hi,> I thought llvm-gcc isn't meant to compile for specific target (at least > with -emit-llvm flag I'm using).No, it is not. C language is highly target-specific, thus LLVM IR obtained from such sources also has the same nice 'property'> Speaking of SPARC ABI can I still call non-FP external (i.e. compiled > with regular non-llvm gcc to native sparc binary) functions from within > LLVM code? Or ABI is competely broken?I think best answer will be: try it and let us know :) Currently there is no active sparc maintainer, thus it will be safe to assume it to be arbitrary broken.> Do you mean calls like __gnu_cxx::__exchange_and_add ?http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
On Tue, 11 Nov 2008, Anton Korobeynikov wrote:>> >> Speaking of SPARC ABI can I still call non-FP external (i.e. compiled >> with regular non-llvm gcc to native sparc binary) functions from within >> LLVM code? Or ABI is competely broken? > > I think best answer will be: try it and let us know :) Currently there > is no active sparc maintainer, thus it will be safe to assume it to be > arbitrary broken.>From my very brief visual inspection it seems like it should probably workfor code that doesn't try and pass or return a structure, complex number, or double precision floating point number by value, or use any type of nifty calling convention like FASTCALL or whatever else gcc defines. This is completely untested though. -Luke>> Do you mean calls like __gnu_cxx::__exchange_and_add ? > > http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.htmlI was actually referring to llvm.atomic.* that is in my .ll code. I get "not-yet-implemented" errors. -Luke
Hi, Anton Korobeynikov wrote:>> I thought llvm-gcc isn't meant to compile for specific target (at least >> with -emit-llvm flag I'm using). > No, it is not. C language is highly target-specific, thus LLVM IR > obtained from such sources also has the same nice 'property'I can see only one reason for such dependence: inclusion of system headers in /usr/include. If I compile llvm-gcc with predefined set of Linux headers (the way cross-compilers are usually made) will the IR output be the same no matter which platform is used for compilation? -- Best Regards Peter Shugalev
On Tue, 11 Nov 2008, Peter Shugalev wrote:> Hi, > > Anton Korobeynikov wrote: >>> I thought llvm-gcc isn't meant to compile for specific target (at least >>> with -emit-llvm flag I'm using). >> No, it is not. C language is highly target-specific, thus LLVM IR >> obtained from such sources also has the same nice 'property' > > I can see only one reason for such dependence: inclusion of system > headers in /usr/include. If I compile llvm-gcc with predefined set of > Linux headers (the way cross-compilers are usually made) will the IR > output be the same no matter which platform is used for compilation?I had trouble with this too -- I still haven't entirely figured it out. Try browsing through http://www.gaisler.com/doc/sparc-abi.pdf which is the SPARC ABI. It explains things like structure padding and stack layout/function calling. llvm-gcc has to make lots of decisions dependent on this ABI when converting C/C++ to IR. I imagine that every platform has its own rules. The SPARC rules actually seem relatively straightforward. -Luke
On Nov 11, 2008, at 10:34 AM, Peter Shugalev wrote:> Hi, > > Anton Korobeynikov wrote: >>> I thought llvm-gcc isn't meant to compile for specific target (at >>> least >>> with -emit-llvm flag I'm using). >> No, it is not. C language is highly target-specific, thus LLVM IR >> obtained from such sources also has the same nice 'property' > > I can see only one reason for such dependence: inclusion of system > headers in /usr/include. If I compile llvm-gcc with predefined set of > Linux headers (the way cross-compilers are usually made) will the IR > output be the same no matter which platform is used for compilation? >No. Consider use of sizeof(), ABI issues, etc. --Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2624 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081111/e39dab81/attachment.bin>