On 07.11.2016 20:12, Philipp Klaus Krause wrote: > On 03.11.2016 12:14, Philipp Klaus Krause wrote: >> On 03.11.2016 00:56, alvin albrecht wrote: >>> >>>> * Install LLVM 3.8 (e.g. using apt-get on Debian). > release_38 for cfe.
Much better, everything compiles fine. The llvm-cbe seems to be geared toward compiling for gcc and msvc and defines a number of macros in the course of its code generation, some of which I had to define to eliminate them from the source. #define __attribute__(x)= #define __builtin_unreachable(x)= #define static inline=inline This last one was at your suggestion to remove the extra unused static inline functions that llvm was producing and this did work. This is not an exhaustive list; I also ran into a "__UNALIGNED_LOAD__()" which is a struct copy. I hand edited those to memcpy but this is less than ideal as some of those struct copies could probably be eliminated. There are probably more macros waiting to appear. The compile sequence I am using is feeding to clang plain header files (without fastcall, callee, preserves_regs attributes) and then taking the resulting .cbe.c from llvm-cbe and feeding that into sdcc with sdcc header files enabled (ie fastcall, callee, preserves_regs are re-instated). These attributes make quite a big difference to compiled code quality so this is the way it has to be done to give the cfe/llvm a chance to generate competitive code. What's happening is the cfe is expanding the header files, the llvm-cbe only sees the prototypes and it outputs prototypes only in the .cbe.c code. What I would want is for the #include headers to remain intact in the .cbe.c file and llvm-cbe not to generate any prototypes. I hand edited the .cbe.c files to remove the prototypes and added the #includes back before the sdcc compile. The largest working test that I tried using the above process was eliza.c ( http://z88dk.cvs.sourceforge.net/viewvc/z88dk/z88dk/libsrc/_DEVELOPMENT/EXAMPLES/eliza.c?revision=1.7&content-type=text%2Fplain ). It was a painless process with some manual intervention. Because the llvm-cbe for some reason wraps types in structures, I did have to fix some incompatible pointer type errors from sdcc. In particular, the llvm-cbe definition of FILE* as a struct was incompatible with the library's definition of FILE* so I had to cast some instances of stdin to "(void *)stdin". The cfe compile came out to 500 bytes larger than the sdcc compile, about 50% larger in the c compiler generated portion. The wrapped structures led to a lot more temporary variables being generated. sdcc already generates near ideal code for eliza.c so I tried something larger that is not ideally compiled by sdcc: a lisp interpretter clisp.c ( http://z88dk.cvs.sourceforge.net/viewvc/z88dk/z88dk/libsrc/_DEVELOPMENT/EXAMPLES/clisp.c?revision=1.7&content-type=text%2Fplain ). The same sort of manual interventions were applied but I ran into a more difficult problem. llvm-cbe began wrapping some types into structures as pairs. So I ended up with structures containing two 32-bit numbers in a handful of places that made compiling difficult to achieve so I wasn't successful. In both cases I was running opt on the .ll before handing to llvm-cbe. I'm not sure if that made things worse or not because more of those wrapped structures appeared. Anyway it's a start but there's still much to do! ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
