search for: elfarmasmbackend

..., I suspect LLVM ended up generating code for "generic" ARMv4 cpu. This article makes me sick in my stomach. > I skip through MCTargetDesc/ARMAsmBackend.cpp, it seems llvm::createARMAsmBackend > only pickup different ARM ISA for Darwin. As for Linux, I guess we need to tweak > ELFARMAsmBackend? Do we need to modify Clang as well? > > Regards, > chenwj > The backend sounds like the wrong place to implement this feature. I'd have thought the Clang driver would be the ideal place?

...-mcpu=cortex-a9, I suspect LLVM ended up generating code for "generic" ARMv4 cpu. This article makes me sick in my stomach. I skip through MCTargetDesc/ARMAsmBackend.cpp, it seems llvm::createARMAsmBackend only pickup different ARM ISA for Darwin. As for Linux, I guess we need to tweak ELFARMAsmBackend? Do we need to modify Clang as well? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj

Hi all, I've just filed PR12794: Add ARM cpu / subtarget features auto-detection. And I would very much appreciate the community's help to implement this. What motivated this? Well this: http://www.phoronix.com/scan.php?page=news_item&px=MTA5OTM I believe one of the reason the benchmark numbers are totally bogus is that the compilation are done on ARM hosts. Given the benchmarks are

...LLVM ended up generating code for "generic" ARMv4 cpu. This article makes me sick in my stomach. >> I skip through MCTargetDesc/ARMAsmBackend.cpp, it seems llvm::createARMAsmBackend >> only pickup different ARM ISA for Darwin. As for Linux, I guess we need to tweak >> ELFARMAsmBackend? Do we need to modify Clang as well? >> >> Regards, >> chenwj >> > The backend sounds like the wrong place to implement this feature. > > I'd have thought the Clang driver would be the ideal place? The right place to implement this is in lib/Support/Host.cpp...

...Value) { diff --git a/lib/Target/ARM/MCTargetDesc/ARMAsmBackend.cpp b/lib/Target/ARM/MCTargetDesc/ARMAsmBackend.cpp index 1ba6ab0..a2c6f7d 100644 --- a/lib/Target/ARM/MCTargetDesc/ARMAsmBackend.cpp +++ b/lib/Target/ARM/MCTargetDesc/ARMAsmBackend.cpp @@ -561,7 +561,10 @@ public: uint8_t OSABI; ELFARMAsmBackend(const Target &T, const StringRef TT, uint8_t _OSABI) - : ARMAsmBackend(T, TT), OSABI(_OSABI) { } + : ARMAsmBackend(T, TT), OSABI(_OSABI) { + // FIXME: Are there versions of ELF-ARM that do not support data-in-code? + HasDataInCodeSupport = true; + }...

Attached is an example of how to reproduce the issue. It uses a C file that happens to has a bunch of switch statements which are encoded as jump tables, giving us data-in-code. Usage: To build object files with clang via the -integrated-as versus via GCC: $ export NDK_DIR=<my_ndk_dir> $ export LLVM_DIR=<my_llvm_bin_dir> $ make To test that the generated objects contain the same