search for: armasmbackend

...lt;2 x i32> %3, i32 0 %6 = extractelement <2 x i32> %3, i32 0 Broken module found, compilation aborted! Stack dump: 0. Program arguments: /home/rich/test/bin/ecc -cc1 -triple i386-ellcc-linux -emit-obj -disable-free -main-file-name ARMAsmBackend.cpp -mrelocation-model static -fmath-errno -masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.22.52.0.1 -momit-leaf-frame-pointer -coverage-file /home/rich/test/llvm-build-i386-linux/lib/Target/ARM/MCTargetDesc/Release+Asserts/ARMAsmBackend.o -resource-dir /home/r...

> ecc: note: diagnostic msg: /tmp/ARMAsmBackend-265222.cpp > ecc: note: diagnostic msg: /tmp/ARMAsmBackend-265222.sh > ecc: note: diagnostic msg: > > ******************** > The error only occurs for i386. Any ideas? Open a bug report with ARMAsmBackend-265222.cpp and ARMAsmBackend-265222.sh? C...

...gr.jp/builders/clang-3stage-cygwin Not sure, though, r195406 triggered this issue. I am still investigating. I guess it could be reproducible with -target i686-* on other hosts. 2013/11/25 Rafael Espíndola <rafael.espindola at gmail.com>: >> ecc: note: diagnostic msg: /tmp/ARMAsmBackend-265222.cpp >> ecc: note: diagnostic msg: /tmp/ARMAsmBackend-265222.sh >> ecc: note: diagnostic msg: >> >> ******************** >> The error only occurs for i386. Any ideas? > > Open a bug report with ARMAsmBackend-265222.cpp an...

...nst MCInst &Inst); + virtual void EmitMappingSymbol(bool IsData); void fixSymbolsInTLSFixups(const MCExpr *expr); @@ -119,6 +123,11 @@ private: std::vector<LocalCommon> LocalCommons; SmallPtrSet<MCSymbol *, 16> BindingExplicitlySet; + + // FIXME: This information is in ARMAsmBackend, but we currently + // have no way to reach it. + bool IsThumb; + int64_t MappingSymbolCounter; /// @} void SetSection(StringRef Section, unsigned Type, unsigned Flags, SectionKind Kind) { @@ -130,18 +139,21 @@ private: ELF::SHF_WRITE |ELF::SHF_ALL...

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

...records a triple of thumbv7a-linux-androideabi in the bitcode file. >> - The command line for the link step only passes --target= >> arm-linux-androideabi. >> - The default cpu passed to LTO for a triple arm-linux-androideabi is >> the very old arm7tdmi. >> - When the ARMAsmBackend is created from the combination of triple >> thumbv7a-linux-androideabi and cpu arm7tdmi the resultant target >> features only include Thumb1. Amongst other things this prevents MC >> from widening branch instructions to the Thumb2 wide branch. >> - Code generation prior to...

...anup patch that unmasked this issue, I'd like to thank you for putting in the time to delve into things. The patches in question were: * https://reviews.llvm.org/rL321707 * https://reviews.llvm.org/rL321692 > I think that part of this is the same problem that is observed in > PR36542 the ARMAsmBackend that is responsible for widening the tail > call to a Thumb2 branch is created with ARMv4T which doesn't support > Thumb1. There has been a recent change that threads through the > existing SubtargetInfo instead of recreating it from the triple alone. > It is worth mentioning that t...

...8: 00 44 add r0, r0 This shows that we have actually emitted an arm nop (e320f000) instead of a thumb nop. Unfortunately, this encodes to a thumb branch which causes bad things to happen when compiling assembly code with align directives. The ARMAsmBackend class is responsible for emitting these nops. It keeps track of whether it should emit arm or thumb nop. The first problem is that MCElfStreamer does not pass on the `.code 16` directive to the ARMAsmBackend class (using handleAssemblerFlag). In the example above we start assembling in arm mode (be...

...cortex-a7, > this records a triple of thumbv7a-linux-androideabi in the bitcode file. > - The command line for the link step only passes --target= > arm-linux-androideabi. > - The default cpu passed to LTO for a triple arm-linux-androideabi is > the very old arm7tdmi. > - When the ARMAsmBackend is created from the combination of triple > thumbv7a-linux-androideabi and cpu arm7tdmi the resultant target > features only include Thumb1. Amongst other things this prevents MC > from widening branch instructions to the Thumb2 wide branch. > - Code generation prior to MC seems to pref...

...t=arm-linux-androideabi -mcpu=cortex-a7, this records a triple of thumbv7a-linux-androideabi in the bitcode file. - The command line for the link step only passes --target= arm-linux-androideabi. - The default cpu passed to LTO for a triple arm-linux-androideabi is the very old arm7tdmi. - When the ARMAsmBackend is created from the combination of triple thumbv7a-linux-androideabi and cpu arm7tdmi the resultant target features only include Thumb1. Amongst other things this prevents MC from widening branch instructions to the Thumb2 wide branch. - Code generation prior to MC seems to prefer the attributes in...

...ark numbers are totally bogus is that the compilation are done on ARM hosts. Given the benchmarks are apparently compiled without -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 > The backend sounds like the wrong place to implement this feature. I'd ha...

Hi everyone. In ARMAsmBackend.cpp, in routine DarwinARMAsmBackend::ApplyFixup() there is a curious call to getFixupKindNumBytes() - which can return 1,2, 3, or 4 depending upon the FixupKind The code in ApplyFixup() seems to be lifted from the X86. AFAIK, the initial Fixup.Offset() is always divisible by 4, at least for ARM m...

...enchmark numbers are totally bogus is that the compilation are done on ARM hosts. Given the benchmarks are apparently compiled without -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....

...d" } EmitCodeMappingSymbol -> { nop on base class, calling either EmitThumbMappingSymbol or EmitARMMappingSymbol (private) on ARM } > +void MCELFStreamer::EmitMappingSymbol(bool IsData) { > + // FIXME: The following is specific to the ARM. This should be moved > + // to ARMAsmBackend. Maybe MCARMELFStreamer (or whatever sounds nicer than that). ARMAsm is a big bag of code and nowadays, most of it is format agnostic, I think (asm, elf). -- cheers, --renato http://systemcall.org/

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

Matheus, The ARM backend reports these kinds of errors using FatalError method of MCContext. You can see some examples in ARMAsmBackend.cpp (search for "out of range pc-relative fixup value"). -David From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Matheus Almeida Sent: Tuesday, December 03, 2013 5:37 AM To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] Reporting errors when ap...

For a target that hasn't implemented branch relaxation (yet), does anyone know what is the preferred way to report an error if a fixup cannot be applied because, for example, the destination of a branch is out of range? I suppose I could use asserts just like AArch64 is doing but that won't stop the assembler of emitting a branch to an undesired location in release builds. Does anyone see

...numbers are totally bogus is that the compilation are done on ARM hosts. Given the benchmarks are apparently compiled without -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 >> > The backend sounds like the wrong place to impl...

...:createObjectWriter. This allows backend specific stuff in lib/MC/ELFObjectWriter.cpp to be moved to the backend's directory. There are obviously several things that could be done differently: 1. The backend specific ELFObjectWriter classes are declared and implemented in X86AsmBackend.cpp and ARMAsmBackend.cpp; it may be better to put these classes in their own files. 2. The ELFObjectWriter base class is declared in llvm/MC/MCObjectWriter.h; it may be better to put this declaration in its own header file. 3. Some of the flags, such as Is64Bit and EMachine, could be virtual methods instead of values...

...bol -> { nop on base class, calling either > EmitThumbMappingSymbol or EmitARMMappingSymbol (private) on ARM } > > > > +void MCELFStreamer::EmitMappingSymbol(bool IsData) { > > + // FIXME: The following is specific to the ARM. This should be moved > > + // to ARMAsmBackend. > > Maybe MCARMELFStreamer (or whatever sounds nicer than that). ARMAsm is > a big bag of code and nowadays, most of it is format agnostic, I think > (asm, elf). > > > -- > cheers, > --renato > > http://systemcall.org/ > -------------- next part -------------- A...