My compiler emits LLVM IR in text form and passes it to the opt and llc executables.
The datalayout and triple are currently determined by running "clang -x c /dev/null -emit-llvm -S -o -" and parsing the output. This works fine because clang seems to choose a generic version of the CPU it is running on, and this is exactly what we want. Still this solution is hacky and I'd like to know whether there is a cleaner way to achieve this.
The "target-cpu" attribute is not set at all by my compiler. I'm concerned that this limits the effectiveness of certain optimization passes. I don't understand when the triple is used and when the "target-cpu" attribute is used.
The compiler links some other IR, which is generated by clang, into the main IR output of the compiler before optimization. The functions pulled in from the clang outputs have the "target-cpu" attribute set. On X86, the inliner refuses to inline these functions because the features of the CPU model set on the callee are a superset of those of the caller.
It is of course possible to compile a short C function with clang and fish the "target-cpu" attribute out of the IR. However, I don't want to introduce another hack.
Can someone recommend a cleaner way to get the datalayout and "target-cpu" attribute for a generic model of the CPU we're compiling on?
Also, your compiler could easily just produce the final object file directly instead of calling opt/llc (mimic opt.cpp and llc.cpp for instance, or what clang is doing).
I think this will give me the "fastest" CPU model and feature set available. However, I want a generic model, which is "x86-64" in my case.
Also, your compiler could easily just produce the final object file
directly instead of calling opt/llc (mimic opt.cpp and llc.cpp for
instance, or what clang is doing).
Sorry for not having stated that more explicitly. My compiler can only output a text file and doesn't link against LLVM libraries.
I think this will give me the "fastest" CPU model and feature set available. However, I want a generic model, which is "x86-64" in my case.
Also, your compiler could easily just produce the final object file
directly instead of calling opt/llc (mimic opt.cpp and llc.cpp for
instance, or what clang is doing).
Sorry for not having stated that more explicitly. My compiler can only output a text file and doesn't link against LLVM libraries.
You can process the IR directly with clang as well