I am writing an llvm tool that uses the generated llvm IR bit code. and for va_arg clang expands it into
getelementptr instruction
with fixed positions and memory layout
instead of using
va_arg instruction
is there any compiler flag to disable this expansion ?
AFAIK, no, because variable argument handling is platform-specific.
Moreover, I tried to use VA instructions from LLVM IR and sometimes it was resulting in wrong machine code. There are a lot of intricacies there, and that's why IR VA instructions are going to be deprecated.
Related
In which scenarios should I care about it/place it for LLVM?
I have read the following doc but need more detailed examples if anyone could lift .What does volatile mean exactly in LLVM?
Citation: Volatile Memory Accesses, where "volatile" is defined in LLVM.
just found out, that _mm_broadcastsd_pd, which is listed in the intel intrinsics guide (link), is not implemented in GCCs avx2intrin.h. I tested a small example on Godbolt with the latest GCC version and it won't compile (Example GCC). Clang does (Example Clang). It's the same on my computer (GCC 8.3).
Should I file a bug report or is there any particular reason why it is not included? I mean, sure, _mm_movedup_pd does exactly the same thing and clang actually generates the same assembly for both intrinsics, but I think that shouldn't be a reason to exclude it.
Greetings
Edit
Created a bug report: link
Not all compilers have all aliases for an intrinsic (different names for the same thing). Other than trying them on Godbolt, IDK how to find out which ones are portable across current versions of the major 4 compilers.
But yes, GCC/clang do accept bugs about missing _mm intrinsics, especially ones that Intel documents.
_mm_broadcastsd_pd is documented by Intel as being an intrinsic for movddup so you're not missing out on anything. More importantly, it's a bit misleading because there is no vbroadcastsd xmm, xmm, only with a YMM or ZMM destination. (_mm256_broadcast_sd(double *a); and _mm256_broadcastsd_pd(__m128d a);)
The asm reference manual doesn't even document _mm_broadcastsd_pd in the vbroadcast or the movddup entry; it's only in the intrinsics guide.
GCC would probably want to add this, especially since clang has it. Having _mm_broadcastsd_pd as an alias would be useful for people that are looking for it and don't know the asm well enough to know that they need a movddup. (Or with AVX 3-operand instructions, movlhps or unpcklpd same,same)
Object code can be disassembled in to an assembly language. Is there a way to turn object code or an executable into LLVM IR?
I mean, yes, you can convert machine language to LLVM IR. The IR is Turing-complete, meaning it can compute whatever some other Turing-complete system can compute. At worst, you could have an LLVM IR representation of an x86 emulator, and just execute the machine code given as a string.
But your question specifically asked about converting "back" to IR, in the sense of the IR result being similar to the original IR. And the answer is, no, not really. The machine language code will be the result of various optimization passes, and there's no way to determine what the code looked like before that optimization. (arrowd mentioned McSema in a comment, which does its best, but in general the results will be very different from the original code.)
I was searching on the web to find a proper solution, without much success.
So I hope one of you know something about it: Is there any way to detect the "Intel Bit Manipulation Instruction Sets 2" (BMI2) compile time? I want to make some conditional thing based on the availability of it.
With GCC you can check for the __BMI2__ macro. This macro will be defined if the target supports BMI2 (e.g. -mbmi2,-march=haswell). This is the macro that the instrinsic's headers (x86intrin.h, bmi2intrin.h) uses to check for BMI2 at compile time.
For runtime checks, __builtin_cpu_init() and __builtin_cpu_supports("bmi2") can be used in modern GCC (tested in GCC 5.1, 4.9 and lower doesn't have it).
Run the CPUID intrinsic function with EAX=7, ECX=0, then check bit 3 of the returned EBX register (the BMI1 flag). EBX bit 8 is the BMI2 flag. Consult your compiler's documentation for how to call CPUID and get the data back from it.
I have written an LLVM pass that modifies the Intermediate Representation (IR) code. To increase portability, I also want it to work with a gcc compiler. So I was wondering if there is any tool which can convert some Intermediate Representation (IR) of gcc to LLVM IR.
You probably want dragonegg (which is using the GCC front-end to build an LLVM IR).
And if you wanted to work on the GCC internal representations, MELT (a high level domain specific language to extend GCC) is probably the right tool.
It will probably be much easier to simply write another version of your code that works with gcc IR. What you want to do is likely not possible, and if it is possible, it's probably extremely difficult. (More so than writing the LLVM pass in the first place.)