search for: debug_values

...ert an DEBUG_VALUE in all the MachineBasicBlocks where vregX is used. (pre regalloc) > > I prototyped a small pass to do that and at first it seems to improve .debug_loc range validity and enhance the debugging experience for optimized code. The problem that I see with this approach is that DEBUG_VALUEs are only valid until the next DEBUG_VALUE that describes the same variable. How does your pass handle: BB0: DEBUG_VALUE “x”, vreg0 | | | BB1: | DEBUG_VALUE “x”, vreg1 | | \_____BB2: | | |____/ BB2: vreg0 // still not clobbered here. Does it insert a DEBUG_VALU...

...in all the MachineBasicBlocks where vregX is used. (pre regalloc) > > > > I prototyped a small pass to do that and at first it seems to improve .debug_loc range validity and enhance the debugging experience for optimized code. > > The problem that I see with this approach is that DEBUG_VALUEs are only valid until the next DEBUG_VALUE that describes the same variable. How does your pass handle: > > BB0: > DEBUG_VALUE “x”, vreg0 > > | | > | BB1: > | DEBUG_VALUE “x”, vreg1 > | | > \_____BB2: > | | > |____/ > BB2: >...

...neBasicBlocks where vregX is used. (pre regalloc) >> > >> > I prototyped a small pass to do that and at first it seems to improve .debug_loc range validity and enhance the debugging experience for optimized code. >> >> The problem that I see with this approach is that DEBUG_VALUEs are only valid until the next DEBUG_VALUE that describes the same variable. How does your pass handle: >> >> BB0: >> DEBUG_VALUE “x”, vreg0 >> >> | | >> | BB1: >> | DEBUG_VALUE “x”, vreg1 >> | | >> \_____BB2: >> |...

I spent some time digging into a Valgrind report of uninitialized values in LLVM r287520 built using itself. (One of quite a few such reports that comes up during a "make check".) I could use another set of eyes on the issue if someone has time. This command gives me an error: valgrind -q ./bin/llc < /home/regehr/llvm/test/CodeGen/Hexagon/hwloop-dbg.ll -march=hexagon

...ere vregX is used. (pre regalloc) >>> > >>> > I prototyped a small pass to do that and at first it seems to improve .debug_loc range validity and enhance the debugging experience for optimized code. >>> >>> The problem that I see with this approach is that DEBUG_VALUEs are only valid until the next DEBUG_VALUE that describes the same variable. How does your pass handle: >>> >>> BB0: >>> DEBUG_VALUE “x”, vreg0 >>> >>> | | >>> | BB1: >>> | DEBUG_VALUE “x”, vreg1 >>> | | >&gt...

Just want to emphasize that on x86-64 and using Valgrind: LLVM compiled with LLVM gets 360 unexpected test fails LLVM compiled with GCC gets 22 unexpected test fails Of course I don't know how many of these are caused by this bitfield speculation issue. John On 11/21/2016 10:48 PM, regehr via llvm-dev wrote: > Alright, here's what seems to be happening... > > The testcase

Hi all, An early implementation of extending debug ranges and providing multiple location support is done here: http://reviews.llvm.org/D11933 Design document: https://docs.google.com/document/d/1noDVWTvTWBdYdweICPBwvwyt8QvX4KHl7j3XKNSg1nE/edit?usp=sharing On Jun 24, 2015, at 12:12 PM, Alexey Samsonov <vonosmas at gmail.com> wrote: Hi Adrian, You might want to take a look at abandoned

For the given test: class A1 { int x; int y; public: A1(int a, int b) { x=a; y=b; } A1 operator+(const A1&); }; A1 A1::operator+(const A1& second) { A1 sum(0,0); sum.x = x + second.x; sum.y = y + second.y; return (sum); } int main (void) { A1 one(2,3); A1 two(4,5); return 0; } when the exectable of this code is debugged in gdb for i386, we dont get the

On Fri, 2018-02-09 at 12:54 +0000, David Woodhouse wrote: > On Fri, 2018-02-09 at 10:36 +0000, David Woodhouse wrote: > >  > > Did you get anywhere with the function attribute? Having isolated the > > next boot failure to "it goes away if I compile io_apic.c without > > retpoline", bisecting it per-function would help to further delay the > > bit where I

On Fri, 2018-02-09 at 10:36 +0000, David Woodhouse wrote: > > Did you get anywhere with the function attribute? Having isolated the > next boot failure to "it goes away if I compile io_apic.c without > retpoline", bisecting it per-function would help to further delay the > bit where I actually have to start *thinking*... It's mp_register_ioapic(), and only when

On Jun 2, 2011, at 6:20 AM, Rafael Ávila de Espíndola wrote: > On 11-06-02 6:56 AM, Anton Korobeynikov wrote: >> Hi Chip, >> >>> Because of all this, it's hard to reconstruct the SEH information from >>> the MachineMove array. I have thought about adding a new array specific >>> to SEH information, but I'm not sure how you guys would feel about

I was told that my writeup lacked an example and details so I reproduced the code that X uses and I was able to boil down the issue to a couple of lines of code. Sorry again for the length of this email. Code was compiled on OpenBSD with clang 3.0-release. ======================================================================== With -O0 which works as X expects:

Problem seems not only with operator overloading, It occurs with struct value returning also. gdb while debugging expects the return value in eax, gcc does returns in eax, But Clang returns in edx(it can be checked in gdb by printing the contents of edx). Code(sample code) struct A1 { int x; int y; }; A1 sum(const A1 one, const A1 two) { A1 plus = {0,0}; plus.x = one.x + two.x; plus.y

On 11-06-02 6:56 AM, Anton Korobeynikov wrote: > Hi Chip, > >> Because of all this, it's hard to reconstruct the SEH information from >> the MachineMove array. I have thought about adding a new array specific >> to SEH information, but I'm not sure how you guys would feel about that. >> Any ideas on how to solve this problem? > Same problem with

Hi Jonas, Thanks for taking a look! It makes linear-dbg-value.ll pass for my target by producing DEBUG_VALUEs correctly. I also tried a simple function with few operations and confirmed DEBUG_VALUEs which are not produced without trasferDbgValues in SetPromotedInteger. Thanks, Sejong From: jdevlieghere at apple.com <jdevlieghere at apple.com> Sent: Wednesday, March 14, 2018 4:07 AM To: Se Jong Oh &...

Hi, Structures are passed by pointer, so the return value is not actually in eax. That code gets transformed into something like: void sum(A1 *out, const A1 one, const A1 two) { out->x = one.x + two.x out->y = one.y + two.y } So actually the function ends up returning void and operating on a hidden parameter, so %eax is dead at the end of the function and should not be being relied

> On Mar 14, 2018, at 7:55 PM, Se Jong Oh <sejooh at microsoft.com> wrote: > > Hi Jonas, > > Thanks for taking a look! It makes linear-dbg-value.ll pass for my target by producing DEBUG_VALUEs correctly. I also tried a simple function with few operations and confirmed DEBUG_VALUEs which are not produced without trasferDbgValues in SetPromotedInteger. That’s great news! Do you plan on creating a patch for this upstream? > > Thanks, > Sejong > > From: jdevlieghere at...

I haven't read the all the emails in full detail, but it seems pretty clear that __x86_indirect_thunk and __llvm_retpoline_push do not do the same things. It sounds like __llvm_retpoline_push is equivalent to __x86_indirect_thunk except first it swaps the two words on the top of the stack. I arranged it this way because the x86 call instruction puts the intended return address on the top of

...18 at gmail.com Subject: Re: [llvm-dev] [SelectionDAG] DbgValue nodes aren't transferred > On Mar 14, 2018, at 7:55 PM, Se Jong Oh <sejooh at microsoft.com> wrote: > > Hi Jonas, > > Thanks for taking a look! It makes linear-dbg-value.ll pass for my target by producing DEBUG_VALUEs correctly. I also tried a simple function with few operations and confirmed DEBUG_VALUEs which are not produced without trasferDbgValues in SetPromotedInteger. That’s great news! Do you plan on creating a patch for this upstream? > > Thanks, > Sejong > > From: jdevlieghere at...

Hi, we at Arm have noticed that assembly can differ when compiling for AArch64 depending on whether debug information is generated or not. The issue is reproducible for the following small example compiled with `-O1` for `aarch64-arm-linux-gnu`: a() { b(a); for (;;) c("", b); } The reason for the difference is that AArch64 frame lowering emits CFI