similar to: Proposal for multi location debug info support in LLVM IR

Thanks for your comments. Replies inline. > The DWARF 5 standard says that > "Address range entries in a range list may not overlap.” > > The reasoning behind this is presumably that if a variable is in more than > one > location at a point all the values need to be identical, or the > information is useless Oh huh, for some reason I was under the impression that they

On Tue, Jan 5, 2016 at 6:59 PM, Adrian Prantl <aprantl at apple.com> wrote: > Thanks for the clarification, Paul! > Keno, just a few more questions for my understanding: > > > - Indicating that a value changed at source level (e.g. because an > > assignment occurred) > > This is done by a key call. Correct > > - Indicating that the same

I will be out of the office on January 7th and will return on January 19th. I will not have access to email during this time. Please contact Karen Lavelle at klavelle at rice.edu or 713-348-2062 if you have any questions or concerns. Best regards, Annepha On Jan 6, 2016, at 3:58 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Jan 5, 2016, at 10:37 AM,

Adrian had proposed the following staging: 1. Remove offset argument from dbg.value 2. Unify dbg.value and dbg.declare 3. Full implementation I'm not yet sure what to do about the difference in dbg.declare semantics. For example, i think the following currently works ``` top: %x = alloca br else if: dbg.declare(%x... unreachable else: # dbg.declare still applies here ``` I think it would

Typing nbdsh --con (the minimum to get an unambiguous prefix for --connect, different from --command) is annoying compared to having a short option. Since it takes a URI as an argument, using -u seems like a reasonable mnemonic. --- sh/nbdsh.pod | 6 ++++-- python/nbdsh.py | 2 +- sh/test-context.sh | 8 ++++---- sh/test-pattern.sh | 2 +- 4 files changed, 10 insertions(+), 8

We decided to not request the "base:allocation" context by default (if a client wants to use block_status on a different context, then they'd have to get any default request out of the way); however, block status is useless without at least one meta context. This adds a convenience knob for requesting that, and has the nice benefit of working with the --connect command line option

I'm going to show the same function, first normally, and then as a coroutine, and show how gdb can see the variable when it's a normal function, but not when it's a coroutine. I'd like to understand if this can be improved. I'm trying to debug a real world problem, but the lack of debug info on variables in coroutines is making it difficult. Should I file a bug? Is this a

Typing nbdsh --con (the minimum to get an unambiguous prefix for --connect, different from --command) is annoying compared to having a short option. Since it takes a URI as an argument, using -u/--uri is a nicer mnemonic. We still accept --connect for back-compat, and document it in the man page, but omit it from --help as the new spelling is nicer all around. --- Here's what things evolved

> On Nov 18, 2019, at 8:33 AM, Jeremy Morse <jeremy.morse.llvm at gmail.com> wrote: > > Hi llvm-dev@, > > Switching focus to the LLVM implementation, the significant change is > using dbg.value's first operand to refer to a DILocalVariable, rather > than a Value. There's some impedance mismatch here, because all the > documentation (for example in the

>As the person who has advocated for DW_OP_LLVM_arg(N) before, my main motivation was to resolve the ambiguity of constant DIExpressions: As a worst-case example: > >dbg.value(%undef, !DILocalVariable(x), DIExpression(DW_OP_constu, 42)) > >Is this undefined, or constant 42? > >But if we make dbg.value fully variadic with all parameters pushed to the stack ahead of time, we can

I did not observe any assertion. In addition, the documentation ( https://llvm.org/docs/LangRef.html#undefined-values) says: The string ‘undef’ can be used anywhere a constant is expected, and indicates that the user of the value may receive an unspecified bit-pattern. Undefined values may be of any type (other than ‘label’ or ‘ void’) and be used anywhere a constant is permitted. Either way,

RFC: A proposal for vectorizing loops with calls to math functions using SVML (short vector math library). ========= Overview ========= Very simply, SVML (Intel short vector math library) functions are vector variants of scalar math functions that take vector arguments, apply an operation to each element, and store the result in a vector register. These vector variants can be generated by the

Hi, I have the below test case. --snip-- struct st { int a; int b; }; int * ptr; int x,y; void bar(int *x); void foo() { struct st obj; bar(&obj.b); if(x) obj.a =x; else obj.a =y; for (int i=0; i<obj.a;i++) ptr[i]=i; } --snip-- LLVM IR produced at -O3 is shown below. ref: https://godbolt.org/z/WPlmfr --Snip-- %8 = getelementptr inbounds %struct.st,

Hi Sanjay, For sincos calls, I’m currently just going through isTriviallyVectorizable(), which was good enough to get things working so that I could test the translation. I don’t see why this cannot be changed to use addVectorizableFunctionsFromVecLib(). The other functions that I’m working with are already vectorized using the loop pragma. Those include sin, cos, exp, log, and pow. From: Sanjay

I have this input IR in the final cleanup block of my coroutine: // call the free function call fastcc void %22(%Allocator* %20, %"[]u8"* byval %4), !dbg !244 // based on whether this is an early return or a normal return, we want to // either return to the caller, or resume the handle of the awaiter br i1 %19, label %Resume, label %Return, !dbg !244 Resume:

Hi all, In several of our tests, I have noticed that the register allocator allocates to virtual registers in a different order when compiling with the clang option -g. Before entering the register allocator, the code is identical when compiling with and without -g (with the exception of " DBG_VALUE" instructions). The only difference I can see is the value assigned to the slot index

> On Nov 12, 2014, at 1:00 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > If you don't care about function-local metadata and debug info > intrinsics, skip ahead to the section on assembly syntax in case you > have comments on that. > >> On 2014-Nov-09, at 17:02, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> >>

On 8 January 2018 at 11:15, Kaylor, Andrew via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Kevin, > > Thanks for reaching out about this, and thanks especially for offering to > help. I've had some other priorities that have prevented me from making > progress on this recently. > > As far as I know, there is no support at all in clang for handling the >

Yes, it's still respected in this case, as the only instructions that will be deleted have been RAUW with undef. Originally, all instructions where RAUW but only non-EHPad were deleted (that means EHPad were RAUW but not deleted). Then it was later patched by not RAUW token instructions and now not deleting EHPad nor token instructions. My assumption is that the instructions we wanted to

Here's what this function is supposed to do: // Move early uses of spilled variable after CoroBegin. // For example, if a parameter had address taken, we may end up with the code // like: // define @f(i32 %n) { // %n.addr = alloca i32 // store %n, %n.addr // ... // call @coro.begin // we need to move the store after coro.begin in the