similar to: [LLVMdev] LLVM ERROR: expected relocatable expression

On Fri, Sep 20, 2013 at 2:50 PM, Sid Manning <sidneym at codeaurora.org> wrote: > > This example generates the following error: > .Ltmp3: > .Ltmp5: > .Ltmp13: > .word (.Ltmp5-.Ltmp3)-.Ltmp13 > > ./llvm-mc ex.s -filetype=obj > LLVM ERROR: expected relocatable expression when using: > > Umm, isn't this equivalent to the following? What do you

On 09/20/2013 06:00 PM, Eli Friedman wrote: > On Fri, Sep 20, 2013 at 2:50 PM, Sid Manning <sidneym at codeaurora.org > <mailto:sidneym at codeaurora.org>> wrote: > > > This example generates the following error: > .Ltmp3: > .Ltmp5: > .Ltmp13: > .word (.Ltmp5-.Ltmp3)-.Ltmp13 > > ./llvm-mc ex.s -filetype=obj >

On Sun, Sep 22, 2013 at 12:23 PM, Sid Manning <sidneym at codeaurora.org>wrote: > On 09/20/2013 06:00 PM, Eli Friedman wrote: > >> On Fri, Sep 20, 2013 at 2:50 PM, Sid Manning <sidneym at codeaurora.org >> <mailto:sidneym at codeaurora.org**>> wrote: >> >> >> This example generates the following error: >> .Ltmp3: >>

On Sun, May 11, 2014 at 8:19 AM, Stephan Tolksdorf <st at quanttec.com> wrote: > Hi, > > When clang/LLVM can't prove that a noexcept function only contains > non-throwing code, it seems to insert an explicit exception handler that > calls std::terminate. Why doesn't clang leave it to the eh personality > function to call std::terminate when an exception is thrown

I wonder why AVX is not used automatically if available at the host machine. In contrast to that, SSE41 instructions (like pmulld) are automatically used if the host machine supports SSE41. E.g. $ cat avx.ll define void @_fun1(<8 x float>*, <8 x float>*) { _L1: %x = load <8 x float>* %0 %y = load <8 x float>* %1 %z = fadd <8 x float> %x, %y store

On Thu, 24 May 2012, Pan, Wei wrote: > Very likely AVX is not enabled in your llc. This feature was enabled > just recently (late of April). I forgot to mention that I am using recent LLVM-3.1 and in principle my llc knows about avx as I have shown in the second example. But avx does not seem to be used by default. On Thu, 24 May 2012, Henning Thielemann wrote: > $ llc -o - -mattr

Hi I use BlockAddress to get the address of BasicBlock , and I use GlobalVariable 's getInitializer() to pass the address of BasicBlock to the global variable of my own program and then I print it out. But , I found that BlockAddress is not always correct. For example, some function's rsp (stack pointer) or other register is maintained by caller, so it would be like:

Prompted by a SO post (http://stackoverflow.com/questions/9441882/compiler-instruction-reordering-optimizations-in-c-and-what-inhibits-them/9442363) I checked and found that LLVM yields the same (seemingly) suboptimal code as MSVC. Consider the following, simplified, C snippet: extern void bar(int*); void foo(int a) { int ar[100] = {a}; if (a) return; bar(ar); }

Hi LLVM and GCC developers, My sincere thanks will goto: * Duncan, the core developer of llvm-gcc and dragonegg http://llvm.org/devmtg/2009-10/Sands_LLVMGCCPlugin.pdf * David, the innovator and developer of GCC https://dmalcolm.fedorapeople.org/gcc/global-state/requirements.html and others who give me kind response for teaching me patiently and carefully about how to migrate GCC v4.8.x to

Henning, I believe the code that is supposed to do this is in: lib/Target/X86/X86Subtarget.cpp in X86Subtarget::AutoDetectSubtargetFeatures() Is there a bug in that function? -Hal On Thu, 24 May 2012 23:56:48 +0200 (CEST) Henning Thielemann <llvm at henning-thielemann.de> wrote: > > On Thu, 24 May 2012, Pan, Wei wrote: > > > Very likely AVX is not enabled in your llc.

On Sun, Sep 22, 2013 at 9:43 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Hi Eli, > > Slightly changed the example :- > > .section somedata > .Ltmpa: > .word 100 > .Ltmpb: > .word 60 > .Ltmpc: > .word 40 > .Ltmpd: > .word (.Ltmpa-.Ltmpb)-.Ltmpc > > The GNU assembler properly handles the above. > > $as -c x.s -o x.o >

Hi Eli, Slightly changed the example :- .section somedata .Ltmpa: .word 100 .Ltmpb: .word 60 .Ltmpc: .word 40 .Ltmpd: .word (.Ltmpa-.Ltmpb)-.Ltmpc The GNU assembler properly handles the above. $as -c x.s -o x.o $readelf -x 4 x.o Hex dump of section 'somedata': NOTE: This section has relocations against it, but these have NOT been applied to this dump. 0x00000000 64003c00

Hi, I have run into the following strange behavior and wanted to ask for some advice. For the C program below, function sum() gets inlined in foo() but the code generated looks very suboptimal (the code is an extract from a larger program). Below I show the 32-bit x86 assembly as produced by the demo page on the llvm home page ("Output A"). As you can see from the assembly, after

Hi all, I'm generating code using CLANG + LLVM 2.9 and would like to inspect formal parameter value for x86 32-bit when -O2 -g is used. It seems that when code is optimized by the compiler DWARF information generated doesn't allow to inspect value of parameter. Trying to inspect parameter value in GDB, parameter is marked as optimized by the compiler and thus I can't track its value.

I don't know much about this, but maybe -mllvm -unroll-count=1 can be used as a workaround? /Patrik Hägglund -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Brent Walker Sent: den 28 mars 2012 03:18 To: llvmdev Subject: [LLVMdev] Suboptimal code due to excessive spilling Hi, I have run into the following strange behavior

On 08/26/2010 13:17, Dale Johannesen wrote: >>> Insn before the error: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, >>> %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... >> >> Odd. I thought TCReturn was being lowered. At any rate can you file >> a bug with the .ll file that causes this? > > It should be getting

Nice! Clever compiler.. On 07/28/2012 08:55 PM, Michael Gottesman wrote: > I can get clang/llvm to emit a rotate instruction on x86-64 when compiling C by just using -Os and the rotate from Hacker's Delight i.e., > > ====== > #include<stdlib.h> > #include<stdint.h> > > uint32_t ror(uint32_t input, size_t rot_bits) > { > return (input>>

On Aug 26, 2010, at 11:34 PMPDT, Yuri wrote: > On 08/26/2010 13:17, Dale Johannesen wrote: >>>> Insn before the error: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, >>>> %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... >>> >>> Odd. I thought TCReturn was being lowered. At any rate can you >>> file a bug

Hi, I am trying to execute a simple hello world program compiled like so: path/to/compiled/clang -o test --target=aarch64-linux-gnu -march=armv8.5-a -fsanitize=hwaddress --sysroot=/usr/aarch64-linux-gnu/ -L/usr/lib/gcc/aarch64-linux-gnu/10.1.0/ -g test.c However, when I look at the disassembly, there is an unknown instruction listed at 0x2d51c: 000000000002d4c0 main: 2d4c0: ff c3 00 d1

I can get clang/llvm to emit a rotate instruction on x86-64 when compiling C by just using -Os and the rotate from Hacker's Delight i.e., ====== #include <stdlib.h> #include <stdint.h> uint32_t ror(uint32_t input, size_t rot_bits) { return (input >> rot_bits) | (input << ((sizeof(input) << 3) - rot_bits)); } ====== Then compile with (assuming you are on OS