search for: eh_return

...fies the register used to pass the exception object to the landing pad (or catch clause), and the latter specifies the register used to pass the typeid object to the landing pad. Where can I know what registers should be used? Or it's just the same as those specified in calling convention? - EH_RETURN: I see some targets define their own EH_RETURN SDNode, others don't. What is EH_RETURN, and under what circumstances I should define my own EH_RETURN SDNode? Is the above list complete? Do I understand their purpose correctly (sort of)? Thanks. Regards, chenwj -- Wei-Ren Chen (陳韋任...

On 1/15/2018 6:49 AM, 陳韋任 via llvm-dev wrote: > - EH_RETURN: > >   I see some targets define their own EH_RETURN SDNode, others don't. > What is EH_RETURN, and under what circumstances I should define my own > EH_RETURN SDNode? This corresponds to a GCC intrinsic used in their unwind routines. It's not really known for its exemplar...

2018-01-19 23:00 GMT+08:00 Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org>: > On 1/15/2018 6:49 AM, 陳韋任 via llvm-dev wrote: > >> - EH_RETURN: >> >> I see some targets define their own EH_RETURN SDNode, others don't. >> What is EH_RETURN, and under what circumstances I should define my own >> EH_RETURN SDNode? >> > > This corresponds to a GCC intrinsic used in their unwind routines. It's &gt...

...============================================================= --- llvm.orig/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp 2007-07-14 16:59:23.000000000 +0200 +++ llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp 2007-07-14 16:59:52.000000000 +0200 @@ -696,7 +696,7 @@ } } break; - case ISD::EH_RETURN: + case ISD::EH_RETURN: { MVT::ValueType VT = Node->getValueType(0); // The only "good" option for this node is to custom lower it. switch (TLI.getOperationAction(Node->getOpcode(), VT)) { @@ -710,6 +710,7 @@ Result = LegalizeOp(Node->getOperand(0));...

...ngly. (record_insns): Create hash table if needed; push insns into hash instead of array. (maybe_copy_epilogue_insn): New. (contains): Search hash table instead of array. (sibcall_epilogue_contains): Remove. (thread_prologue_and_epilogue_insns): Split eh_return insns and mark them as epilogues. (reposition_prologue_and_epilogue_notes): Rewrite epilogue scanning in terms of basic blocks. * insn-notes.def (CFA_RESTORE_STATE): New. * jump.c (returnjump_p_1): Accept EH_RETURN. (eh_returnjump_p_1, eh_returnjump_p...

...r it's just the same as those specified in calling convention? This is an ABI decision that your unwinder needs to know about, but the ones used in a normal function call are fairly typical. I believe the information is transmitted to the __gxx_personality_v0 function via Clang's __builtin_eh_return_data_regno intrinsic, which should be consistent. > - EH_RETURN: > > I see some targets define their own EH_RETURN SDNode, others don't. What > is EH_RETURN, and under what circumstances I should define my own EH_RETURN > SDNode? Not sure about this, I'm afraid. My su...

...de generator to use another register to load (or > move) the function pointer to (right before the callee saved register > restore) but thinking a little further that's nonsense. Why don't define some special op for callee address and custom lower it? I really suggest you to look into eh_return. It's used in some pretty tricky situtation inside eh runtime: it it used to return from some eh runtime code. We already know, how much we should unwind the stack, and what is the handler (sounds similar, right?). Also %eax and %edx are used to return eh data and should be preserved in such fu...

On Sep 18, 2009, at 10:43 AM, Jack Howarth wrote: > On Fri, Sep 18, 2009 at 10:28:15AM -0700, Nick Kledzik wrote: >> So, when these test cases are run, is the binary linked against /usr/ >> lib/libgcc_s.10.5.dylib? or against some just built libgcc_s. >> 10.5.dylib? >> or against some just build libgcc_s.dylib? If either of the >> latter, then >> if you

On 22 Jan 2018, at 14:15, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 1/19/2018 7:21 PM, 陳韋任 wrote: >> I see X86, Mips, XCore and Hexagon define their own EH_RETURN and lower to it, but others don't. May I know why it's so on Hexagon? > > Our exception handling runtime uses __builtin_eh_return. Does this mean that you know what it does? If so, please could you document it somewhere? David

On Fri, Sep 18, 2009 at 10:28:15AM -0700, Nick Kledzik wrote: > So, when these test cases are run, is the binary linked against /usr/ > lib/libgcc_s.10.5.dylib? or against some just built libgcc_s.10.5.dylib? > or against some just build libgcc_s.dylib? If either of the latter, then > if you changed the FSF build of libgcc_s for darwin to have the right > magic symbols, then

On 1/19/2018 7:21 PM, 陳韋任 wrote: > I see X86, Mips, XCore and Hexagon define their own EH_RETURN and lower > to it, but others don't. May I know why it's so on Hexagon? Our exception handling runtime uses __builtin_eh_return. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

On 1/22/2018 8:40 AM, David Chisnall wrote: > On 22 Jan 2018, at 14:15, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On 1/19/2018 7:21 PM, 陳韋任 wrote: >>> I see X86, Mips, XCore and Hexagon define their own EH_RETURN and lower to it, but others don't. May I know why it's so on Hexagon? >> >> Our exception handling runtime uses __builtin_eh_return. > > Does this mean that you know what it does? If so, please could you document it somewhere? I don't actually, but I can find out....

...the pattern it's not a very useful def. Any suggestions? I have other XSGTGPseudo definitions in the .td file which are similar which do compile, like this: def SDT_XSTGEhRet : SDTypeProfile<0, 2, [SDTCisInt<0>, SDTCisPtrTy<1>]>; def XSTGEhReturn : SDNode<"XSTGISD::EH_Return", SDT_XSTGEhRet, [SDNPHasChain, SDNPOptInGlue]>; // // EhReturn takes the place of regular return instruction // but takes two arguments (R2, R3) which are used for storing // the offset and return address respectively. // let Uses = [R2, R3], isTerminator = 1,...

...can: can't the target (which knows the capabilities > of the currently selected subtarget) set the value of > SupportsExceptionHandling correctly? > They do. However, it doesn't seem to stop it from failing during compilation of unwind-dw2.c for libgcc -- it has "__builtin_eh_return" in it. During 4-way FAT PPC compilation, it tries to compile this file and fails during the LowerOperation function. Turning --enable-eh off makes the error go away. It may be my lack of understanding, but it appears that having -- enable-eh set during compilation of llvm-gcc is causing...

...the tc_return node would again be a pseudoop *else lower normal return When generating the epilog the two operands of the the tc_return machine instruction are used to emit code that adjust the stackpointer and jumps to the tailcallee (either label or register). Like it is done for EH_RETURN. in X86RegisterInfo.cpp we would then have TargetRegisterInfo::emitEpilogue() { ... if (RetOpcode== X86::TC_RETURN){ if (isDynamicCallee(RetOpCode)) add esp {stack adjustment from tc_return} jmp {register operand of tc_return} } else add esp {stack adjustment...

On Aug 28, 2007, at 11:20 PM, Duncan Sands wrote: > Hi Bill, > >> This is a (very) rough patch to fix building LLVM with exceptions on >> PPC Darwin. Basically, it puts the burden of adding the "--enable-eh" >> on the specific target, which is where I think it should go. > > I don't like it. LLVM has plenty of features that are not supported > on

...have to insert code into PEI::saveCalleeSavedRegisters to > detect that there is a tail called function that uses a callee saved > register and move it to another (EAX). You shouldn't use call-saved registers at all. Only call-clobbered. It seems, that you can use the trick similar to eh_return lowering (that case is somehow special, because %eax and %edx should be preserved there too). You can see it in TOT for x86 target (also, prologue/epilogue emission code changed on TOT, you might want to check, whether your code works for it). PS: Feel free to contact me in case of any related que...

...s of the TC_RETURN node for the required information. So modifications are: a LowerX86_32FastCCCallTo function a LowerX86_32FastCCArguments function change to LowerRET to generate the TC_RETURN node some code at the end of X86RegisterInfo to do stack adjustment/ jumping to tailcallee (like the EH_RETURN code, thanks Anton for the pointers!) small modifications to X86InstrInfo.td (a yes and at the moment i remove generating TAILCALL nodes in the other functions - LowerCCCall and the like) Another TODO: look a floating point code to see whether there are any kinks. Look at other calling conve...

On Oct 18, 2011, at 2:02 PM, Sanjoy Das wrote: > This about fixing the issue with having a the BB ending with a > non-terminating instruction when compiling with segmented stacks. I'm > not sure if having an isel pseudo instruction which is lowered into a > RET and then a MOV would work better. > LLVMTargetMachine::addCommonCodeGenPasses adds the > ExpandISelPseudosPass

Chris, > That's an easy problem. I just implemented __builtin_return_address > on PPC, at least builtin_return_address(0), please let me know if that > is sufficient. There are bunch of another builtins required for eh to execute properly. The 3 most important one are: - eh_return - unwind_init - dwarf_cfa The first two precisely match to the gcc's ones, the third - slightly differs, because is catches some extra information from the frontend. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.