similar to: [LLVMdev] api changes in llvm 2.4

Hi, Chris Lattner wrote: > In the 2.3 release, we included a list of the major LLVM API changes. If you > are working on upgrading your code from 2.3 to 2.4, I'd appreciate it if you > could compile a list of the major stumbling blocks you have, so that others > can benefit from your experience. Please send any info to the list, thanks! No major stumbling blocks during our

I don't think we can expose the memory operations directly from a semantic, theoretical point of view. Whether practically we can do this or not is a different question. Does LLVM do optimizations like these at the machine instruction level? if (condition) T = *X // normal load, condition guards against null EH_LABEL // clobbers all U = *X // implicit null check, branches

Hello all, I would like to enhance LLVM debug info that supports setting breakpoint on labels in function. Generally, if users use GDB as their debugger, they could set breakpoints on labels in function. Following is an example. // C program static int myfunction (int arg) { int i, j, r; j = 0; /* myfunction location */ r = arg; top: ++j; /* top location */ if (j == 10) goto

On Thu, Apr 23, 2015 at 5:17 PM, Andrew Trick <atrick at apple.com> wrote: > The scheduler itself doesn’t move anything around labels. But any pass can > perform code motion or load/store optimization. Also, any pass can insert > an instruction, like a copy, between the label and the load. > > I’m not really sure how EH_LABEL ends up translating into exception > tables,

LGTM. I think you can sent patch and let the ball rolling! I would like to review it. ;) 2018-03-28 10:41 GMT+08:00 Hsiangkai Wang via llvm-dev <llvm-dev at lists.llvm.org>: > Hello all, > > I would like to enhance LLVM debug info that supports setting > breakpoint on labels in function. > > Generally, if users use GDB as their debugger, they could set > breakpoints on

Sounds good to me. You can also see llvm.codeview.annotation which does a similar thing, but it is modeled as having internal, invisible side effects. These should stay separate, but it may provide a guide for implementation. On Tue, Mar 27, 2018 at 7:41 PM Hsiangkai Wang via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello all, > > I would like to enhance LLVM debug info

> > On Mar 27, 2018, at 7:41 PM, Hsiangkai Wang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello all, > > I would like to enhance LLVM debug info that supports setting > breakpoint on labels in function. > > Generally, if users use GDB as their debugger, they could set > breakpoints on labels in function. Following is an example. > > // C

On Thu, Apr 23, 2015 at 3:31 PM, Andrew Trick <atrick at apple.com> wrote: > > It would be really nice to just emit a label next to an instruction and > assume the stackmap entry will end up at the right address. I don’t think > the backend can make that guarantee. Any Machine pass can insert > instructions wherever it wants without looking for labels. > > I think labels

Thanks Kristof. Sounds like we'll need to investigate though I'd say it is not blocking the switch. At this point I think everybody is on board to flip the switch. @Eric, how does that sound to you? Thanks, Q > Le 1 juin 2017 à 07:46, Kristof Beyls <Kristof.Beyls at arm.com> a écrit : > > >> On 31 May 2017, at 17:07, Quentin Colombet <qcolombet at

Hi all, I added a buildbot [1] running the test-suite with -O0 -global-isel. It runs into the same 2 timeouts that I reported previously on this thread (paq8p and scimark2). It would be nice to make it green before flipping the switch. At the moment, it lives in an internal buildmaster that I've setup for this purpose. If we fix it and it proves to be stable for a week or two, I'll move

Hi all, I've been investigating a machine verifier failure on the attached testcase, and I'm tempted to say the verifier is wrong and should accept it. Skip the description for the proposed change. On AArch64, the verifier complains with: *** Bad machine code: MBB exits via unconditional branch but doesn't have exactly one CFG successor! *** - function: t4 - basic

Hi, I've been experimenting with global isel over the last few weeks and it is such a vast improvement over the SelectionDAG for the AMDGPU target that I would really like to begin using it as soon as possible. Given the lack of a replacement for SelectionDAG's legalizer / combiner, and how much work this will be to implement, I think the fastest path to doing this would be to run some

Hi, I would like to get at the source line number(s) that a BasicBlock is generated from, and the only interface I see to this info in the code is from the debugger. After sifting through that, I think I might be able to do what I want by finding dbg_stoppoint intrinsics, but I'm not sure how to get to them. And, if there's an easy way, that'd be cool to know about. Also, I cant seem

Hi Kristof, Thanks for the updated numbers. > On May 31, 2017, at 7:45 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > >> >> On 31 May 2017, at 15:33, Diana Picus via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Cool test :) >> It seems to work fine now, I don't see any new failures.

> On Apr 1, 2018, at 9:12 AM, Hsiangkai Wang <hsiangkai at gmail.com> wrote: > > Hi all, > > I am sorry that I didn’t carefully think about how to handle labels in > inlined function. There is no need to apologize! Thank you very much for engaging in the discussion and for contributing you patches. > > Today, I did some simple experiments and found that some basic

Hi all, Following the thread from http://lists.llvm.org/pipermail/llvm-dev/2017-January/109029.html, I am sending this email to give a status on GlobalISel progress and situation. We are pushing GlobalISel from the state of prototype to a production quality framework. We welcome help with patches, reviews, feedbacks and so on. As explained during the last developer meeting, we are aiming at

Hi All, For various obscure reasons I'd like to detect the condition when X86 CALL instruction immediately precedes a function epilogue in the final emitted code, and insert a NOP between them if that happens. My initial attempt at it looked like this: MachineBasicBlock& MBB; MachineBasicBlock::iterator MBBI; <-- points to where the epilogue would be inserted if (MBBI != MBB.begin()

Hello all, I am interested in this work, and have tested it a bit so far. In the latest revision, it seems to me that we do not have support in Clang (so it doesn't generate llvm.dbg.label intrinsic) and in Dwarf debug emission (so the backend doesn't generate the DW_TAG_label DIE from the DBG_LABEL Machine Instruction) yet. I attempted to implement these features, do you want me to

On 12 June 2017 at 18:54, Diana Picus <diana.picus at linaro.org> wrote: > Hi all, > > I added a buildbot [1] running the test-suite with -O0 -global-isel. It > runs into the same 2 timeouts that I reported previously on this thread > (paq8p and scimark2). It would be nice to make it green before flipping the > switch. > > I did some more investigations on a machine

Hi Anton & Duncan, When I try to compile on Darwin now, I get this: $ /Volumes/Gir/devel/llvm/llvm-gcc-4.0.obj/gcc/xgcc <options> -o eh_alloc.o Assertion failed: (false && "Couldn't find the register class"), function getPhysicalRegisterRegClass, file /Volumes/Gir/devel/llvm/ llvm.src/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp, line 269.