similar to: [LLVMdev] Why variables get "optimized away" after the last use in unoptimized code?

On 02/02/2014 01:48, David Chisnall wrote: > In most calling conventions, this is a callee-save register. After its last use, the register allocator may reuse that register. On x86 and ARM, the register that contains this is also (usually) the register used for But the rule "after the last use, the register allocator may reuse it" is also introduced by llvm, since register

Eli, Thanks very much for your reply. That's what I want to know. It works for this example. But I usually have to deal with the optimized bytecode with "-O". See the example: ************** C source ************** int h (int j, int i) { int tmp; tmp = j+i+2; return tmp; } +++++++++++++++++++++++++++++++++++++ .ll file: ; ModuleID = 'simplecase.c' target

Dear all, I have the following source code: long f(long x, long y) { long u; u = x+y; return u; }; After clang (with debug option set) and llvm opt using mem2reg, I get the following .ll file *************************************************************************** ; ModuleID = '<stdin>' target datalayout =

Dear All, I am Zahurul Islam. I have found LLVM always generate optimize byte code, but I want to stop this. Actually, I want unoptimized LLVM assembly code from C code. Please help me to do that. regards, Zahurul Islam BRAC University Dhaka,Bangladesh

Hi Devs, Consider testcase here https://godbolt.org/z/qHZzqw When optimization is O1 or above it produces unoptimized code because it calls __tls_get_address in loops. While with optimization disabled It produce single call to __tls_get_address outside of loop. is this a missed optimization by llvm? ./Kamlesh

On Wed, Jul 14, 2010 at 3:03 PM, Arvind Sudarsanam <arvind.sudarsanam at aggiemail.usu.edu> wrote: > Dear all, > > I have the following source code: > > long f(long x, long y) > { >        long u; > >   u = x+y; >   return u; > }; > > After clang (with debug option set) and llvm opt using mem2reg, I get > the following .ll file >

Hi, I want to know the variable mapping between the source and llvm bytecode. It seems that current llvm debugging information cannot provide this mapping directly. Here is my examples (llvm 2.7). In this exmaple, I want to know the mapping: tmp<--->%4. But current llvm's debugging information can only provide that the instruction "%4 = add nsw i32 %3, 2" is at line 3 in

Hi! I created a bug report (https://llvm.org/bugs/show_bug.cgi?id=23712) for this failure but then I realized that my approach may be wrong. The following D source contains a lazy variable: void bar(lazy bool val) { val(); } The lazy variable val is translated to a delegate. The signature and the first IR lines are: define void @_D7opover23barFLbZv({ i8*, i1 (i8*)* } %val_arg) #0 {

I'm not sure if this was intended, but it's going to be a problem for sample profiles. When we compile with -gmlt, the profiler expects to find the line number for all the function headers so that it can compute relative line locations for the profile. The tool that reads the ELF binary is not finding them, so it writes out absolute line numbers, which are impossible to match during the

Hi all, I'm using my own front-end to generate following code .ll file targeting x86 32-bit: ; ModuleID = 'check.c' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32" target triple = "i386-pc-linux-gnu" @.str581 = internal constant [52 x i8] c"---- test number %d

On Thu, Oct 31, 2019 at 11:17 AM Jorg Brown via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Oct 31, 2019 at 8:50 AM kamlesh kumar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi Devs, >> Consider testcase here >> https://godbolt.org/z/qHZzqw >> When optimization is O1 or above it produces unoptimized code >> because it

Hi, I want to get the mapping between C source's variables and bytecode variables. It seems that llvm doesn't provide this mapping, so I think a walk-around method is to get the instruction's mapping. I have to use llvm-gcc, not clang. Any advice? Thanks. Best, Kecheng 2010-05-13 From: Eli Friedman Date: 2010-05-13 15:38:36 To: Kecheng Cc: llvmdev Subject: Re: [LLVMdev] How

Hi all, Anyone have ideas/info on this topic ? Thanks Seb 2012/3/2 Seb <babslachem at gmail.com> > Hi all, > > I'm using my own front-end to generate following code .ll file targeting > x86 32-bit: > > ; ModuleID = 'check.c' > target datalayout = >

On Mar 6, 2012, at 5:31 AM, Seb <babslachem at gmail.com> wrote: > Hi all, > > Anyone have ideas/info on this topic ? > Thanks > Seb > > 2012/3/2 Seb <babslachem at gmail.com> > Hi all, > > I'm using my own front-end to generate following code .ll file targeting x86 32-bit: > > ; ModuleID = 'check.c' > target datalayout =

Hi Folks, I ran into this assertion failure while compiling a function with a large number of arguments: https://llvm.org/bugs/show_bug.cgi?id=21609 I have coded up the fix as per David's suggestion (added a new header field for DIVariable to separate out ArgNo & LineNo). The proposed diff is attached to the bug. However, there are around 175 testcases across clang & llvm that need

On Tue, Apr 28, 2015 at 7:14 PM, David Blaikie <dblaikie at gmail.com> wrote: > I believe duncan's fixed this recently in 235956 and 235955 - does ToT work > for you? It seems like r235955 might have fixed it. However I'm having build issues with ToT in my environment. Is this the right place to check ToT build status: http://lab.llvm.org:8011/one_line_per_build > > On

On Thu, Dec 15, 2016 at 11:38 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Thu, Dec 15, 2016 at 11:26 AM Teresa Johnson <tejohnson at google.com> > wrote: > >> Trying to wrap my brain around this, so a few questions below. =) >> > > Sure thing - sorry, did assume a bit too much arcane context here. > > >> >> On Thu, Dec

Branching off from a discussion of improvements to DIGlobalVariable representations that Adrian's working on - got me thinking about related changes that have already been made to DISubprogram. To reduce duplicate debug info when things like linkonce_odr functions were deduplicated in LTO linking, the relationship between a CU and DISubprogram was inverted (instead of a CU maintaining a list

On Thu, Dec 15, 2016 at 1:30 PM Teresa Johnson <tejohnson at google.com> wrote: On Thu, Dec 15, 2016 at 11:38 AM, David Blaikie <dblaikie at gmail.com> wrote: On Thu, Dec 15, 2016 at 11:26 AM Teresa Johnson <tejohnson at google.com> wrote: Trying to wrap my brain around this, so a few questions below. =) Sure thing - sorry, did assume a bit too much arcane context here.

> On Dec 15, 2016, at 10:54 AM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Branching off from a discussion of improvements to DIGlobalVariable representations that Adrian's working on - got me thinking about related changes that have already been made to DISubprogram. > > To reduce duplicate debug info when things like linkonce_odr functions were