search for: eh_labeling

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

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,

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

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 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()

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

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

On Sat, Apr 05, 2014 at 12:21:17AM -0700, Andrew Trick wrote: > > On Mar 31, 2014, at 6:58 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > > 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

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