search for: eh_label

...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 out on fault EH_LABEL // clobbers all ... => since the second "load" from X always happens, X must be dereferenceable T = *X // miscompile here EH_LABEL // clobbers all U = *X // implicit null check,...

...rick <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, but my guess is that it’s encoding a range that may include any > arbitrary instructions as long as the call is within the range. So as long > as calls aren’t reordered with labels and appears to have side effects it > would work. > > S...

...rt > instructions wherever it wants without looking for labels. > > I think labels are only employed just before code emission. Is there any > existing example of labels being used earlier (I think GCRootLowering is > the earliest)? > SelectionDAGBuilder::lowerInvokable() inserts EH_LABELs into the DAG for normal invokes, and it more or less works out. I don't know much about what transformations MI passes typically do, but my guess is that you're concerned that some pass might re-schedule possibly trapping operations inside the label range? -------------- next part -------...

...erifier complains with: *** Bad machine code: MBB exits via unconditional branch but doesn't have exactly one CFG successor! *** - function: t4 - basic block: BB#5 invoke.cont41 The freshly selected relevant blocks are: BB#7: derived from LLVM BB %invoke.cont41 EH_LABEL <MCSym=Ltmp4> B <BB#8> Successors according to CFG: BB#8(1) BB#9(1) BB#8: derived from LLVM BB %invoke.cont43 Predecessors according to CFG: BB#7 BB#9: derived from LLVM BB %lpad40, EH LANDING PAD Predecessors according to CFG: BB#7...

...t;getPrevNode()->isCall() : MBB.getPrevNode()->back().isCall()) { // insert NOP } However, this did not work because at the stage where I am trying to do this (in X86FrameLowering::emitEpilogue), the MBBs look like this: BB0: ... CALL ... <-- call I am trying to detect EH_LABEL ... <--| these two get eliminated in the final JMP <BB1> <--| emitted code. BB1: <-- the MBB RET <-- MBBI points here So the business of finding the previous "real" instruction is starting to look very complicated. I would need to skip over pseudo-ins...

...-replace in the backend's TargetLowering implementation seemed to fix this. 5) ‘struct llvm::MVT::ValueType’ has not been declared typedef uint32_t ValueType is replaced with struct llvm::MVT. A text replace cured this. 6) error: ‘LABEL’ is not a member of ‘llvm::ISD’ Split to DBG_LABEL and EH_LABEL. In our case we needed only DBG_LABEL. 7) ‘LOCATION’ is not a member of ‘llvm::ISD’ Renamed to DBG_STOPPOINT. 8) error: ‘class llvm::SDValue’ has no member named ‘Val’ SDOperand had 'Val' which can be replaced by getNode(). 9) switch(op.getOperand(1).getValueType()) does not work In o...

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! -Chris

On Sun, Dec 18, 2016 at 11:58 PM, Jonas Maebe <jonas-devlists at watlock.be> wrote: > > Actually, there's another —even more fundamental— problem: the longjmp > will always restore the non-volatile registers to the contents they had > at the start of the try-block, which is not what LLVM expects when > entering an SEH-based landing pad. > The SjLjEHPrepare pass tries

...machine instructions. This will definitely be the case for the Go frontend that I'm working with, as its IR tends to use struct loads/stores quite frequently. So I'm not sure if this will work. I think it needs to look a lot like how the lowering for invokes currently looks, with a pair of EH_LABELs around a set of ordinary load/store MIs -- which is how I implemented it. Thanks, -- Peter

Hi Peter, Thanks for pointing this out. Some us who are concerned with codegen have discussed the problem. Although the details aren't decided, you can be sure that at the MachineInstr level we won't have a landindpadInst to model liveness of exception values. Any physical registers set by the personality function will be considered live immediately after the call on the unwind path.

Chris, it is goodness that the LandingpadInst will be pinned to the beginning of a BasicBlock,... except for the possibility of PHINode instructions that _must_ come even earlier.?. I can't exactly put my finger on what's going to go wrong with this, but it sure smells fishy... my current understanding is that the LandingpadInst will "define" some hard

On Wed, Apr 22, 2015 at 11:44 PM, Andrew Trick <atrick at apple.com> wrote: > > This feature will keep being requested. I agree LLVM should support it, > and am happy to see it being done right. +1 > > I plan to break the design into two parts, roughly following the > > statepoint philosophy: > > > > # invokable @llvm.(load|store)_with_trap intrinsics

Hi, I wanted to propose an IR extension that would allow us to support zero-cost exception handling for non-call operations that may trap. I wanted to start with loads and stores through a null pointer, and later we might extend this to div/rem/mod zero. This feature is obviously useful for implementing languages such as Java and Go which deterministically translate such operations into