search for: l167

...> are in the files 'repro.declare.ll' and 'repro.declare.dwarf.txt'. > > Using an executable built from this IR, I can use lldb to break at the > line where the declare exists, > https://gist.github.com/modocache/8a7b12eb42012990ba534787c4a47275#file-repro-declare-ll-L167 <https://gist.github.com/modocache/8a7b12eb42012990ba534787c4a47275#file-repro-declare-ll-L167>, > using the command 'b repro.cpp:24'. Running 'e i' at this point prints > an incorrect value, '(int) $0 = 24742', but at least 'i' is found. > > Then,...

Hi Brian, On Tue, Feb 25, 2020 at 7:43 PM Brian Gesiak <modocache at gmail.com> wrote: > In other words, the value of %i is stored on the frame object, on the > heap, at an offset of 7 into the frame. I'm beginning to think a > fundamental fix for this issue would be to stop replacing > llvm.dbg.declare with llvm.dbg.value, and instead replace the > llvm.dbg.declare with

Hi Team, I observer that division of __int128 bit is very heavy operation. It internally call a routine '__udivti3', which internally call ' __udivmodti4'. Due to it the overall performance is much much slower (almost 15 time slower than if I do it via a combination of 64-bit or microsoft '_udiv128'). Also what to know if I can directly call below routine directly from

...es 'repro.declare.ll' and 'repro.declare.dwarf.txt'. > > > > Using an executable built from this IR, I can use lldb to break at the > > line where the declare exists, > > https://gist.github.com/modocache/8a7b12eb42012990ba534787c4a47275#file-repro-declare-ll-L167, > > using the command 'b repro.cpp:24'. Running 'e i' at this point prints > > an incorrect value, '(int) $0 = 24742', but at least 'i' is found. > > > > Then, continuing past a coroutine "suspend point" (a point after which > &g...

...specially the collection code pieces. For context, I've previously written some code to pretty-print the line-table information as code comments (sample https://gist.github.com/vtjnash/2f2b642663655d5fc63ec7321c5bd0bd, implementation https://github.com/JuliaLang/julia/blob/master/src/disasm.cpp#L167), and it's been on my mind ever since to figure out if some portion of that made sense to upstream, if any. And also to figure out how to parse and show the variable info along it. So even if none of this PR ends up in the libllvm library, I'd still plan to someday figure out which bits of...

Dear Nut-Devs, I have general question to the contribution and the handling of new code in the NUT-Project. We would like to implement our USV-Solution as a driver to NUT, but we are having the problem, that we need a powerful “C”-based gpio library for it. We discussed this topic internally, and we are having the opinion, that it does make sense, to write this library separate from a

Hi llvm-dev, I've uploaded a prototype patch at https://reviews.llvm.org/D70720 which adds a new feature to llvm-objdump: displaying the location (in registers/memory/etc) of source-level variables alongside the disassembly display. I've put a demo of the output at https://reviews.llvm.org/M2. I have two use-cases in mind for this: * Users reading the disassembly of compiled code. It