Hi,
Im trying to generate C source from C++ source file,
using C backend.
llvm-g++ -O3 -emit-llvm valen.cpp -c -o valen.bc
llc -march=c valen.bc -f -o valen.c
But C backend generate a lot of operation with "long long" type.
My C compiler does not support "long long" type.
Is there any option to disable generate "long long" ?
If your compiler does not support long long, there are a whole bunch of
*other* parts of the C standard that it does not satisfy, and you will
probably find that you will fight other unnecessary battles.
One possibility would be to compile CLANG+LLVM for your target. If that
is not possible, perhaps GCC?
shap
The C backend generates long long for 64-bit integer types. If you're C compiler doesn't support a 64-bit integer type, you'll have problems. If it does, but spells it differently, you could hack the CBE to produce the right name.
-Chris
Thanks,
i will take a look.
Delayed reaction. Chris's response that the emitted code relies on long
long to be a 64-bit type just sunk in.
Chris: is there some reason why the backend does not #include <stdint.h>
and then emit [u]int64_t (and the other sized types as well) and also
[u]intptr_t?
I'm thinking that this would make it a bit easier to re-target things,
and possibly also preserve more documentation of intent in the emitted
code.
shap
The CBE output can't #include standard headers, the macros and types that are defined in the headers will conflict.
-Chris
Not to mention that this header is not present on all plateform, for example the one that use WORD and DWORD as common integer types does not provide a stdint file.
Is that true for the freestanding header files? We have not found it so
in the C backend for BitC, though admittedly it was a design objective
to avoid exactly these conflicts. I would think, in particular, that
stdint.h and inttypes.h would both be safe.
shap
Yes. The only exceptions to the rule have been alloca.h, setjmp.h and stdarg.h, and even those have been a huge pain and we avoid them on platforms where we can.
One example problem is that llvm doesn't preserve signedness of types, so you end up with a header defining:
void foo(int);
and the CBE emits a prototype of:
void foo(unsigned);
which leads to compilation failures.
-Chris
9 years later and they still aren't C99 compliant? Gack.
Regardless, my main point was that using descriptive type names might be
a good thing. I'm not stuck on stdint.h as the particular solution.
Hmm. Yes, I can see why that might make things difficult. Thanks for
taking the moment to answer, and this also nixes my comment about
descriptive integral type names.
shap