similar to: Exception handling support for a target

On 15 January 2018 at 12:49, 陳韋任 via llvm-dev <llvm-dev at lists.llvm.org> wrote: > - CFI directives: > > This is for .eh_frame section. Basically all the targets insert CFI > directives in FrameLowering, but I am not sure exactly when/where I should > do so. The directives are there to describe where the unwinder should look to find out what each register's value

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 exemplary documentation, so you may need to

2018-01-16 18:18 GMT+08:00 Tim Northover <t.p.northover at gmail.com>: > On 15 January 2018 at 12:49, 陳韋任 via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > > - CFI directives: > > > > This is for .eh_frame section. Basically all the targets insert CFI > > directives in FrameLowering, but I am not sure exactly when/where I > should > > do

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

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

2018-01-16 21:03 GMT+08:00 Tim Northover <t.p.northover at gmail.com>: > On 16 January 2018 at 12:23, 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw> wrote: > > Do we have to emit directives in the epilogue, too? One of my test case > fail > > due to the directives in the epilogue have been executed. After removing > > them from epilogue, the exception is caught as

On 16 January 2018 at 12:23, 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw> wrote: > Do we have to emit directives in the epilogue, too? One of my test case fail > due to the directives in the epilogue have been executed. After removing > them from epilogue, the exception is caught as expected. Emitting directives in the epilogue is hard because the directives apply to all instructions

On 16 January 2018 at 13:41, 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw> wrote: > bar: > > .cfi_def_cfa_offset 16 > epilogue > > _Unwind_Resume > > > > The lookup phase of exception handling is fine. However, something goes > wrong in cleanup phase. The reason is the unwinder evaluates CFI directives > until _Unwind_Resume, and `.cfi_def_cfa_offset

Hello, Arnold. > with the sentence i tried to express the question whether there is a > way to persuade the code 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

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

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 Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com> wrote: > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if the > attributes changed). Do you have another solution in mind ? I don't really understand this. TargetMachine and TTI may be quite expensive to initialize. Doing so for

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

The high level of what happens is that __builtin_eh_return forces a spill of all the non-volatile registers. The unwinder then has a starting point for populating and adjusting those non-volatile registers. This approach usually requires that the function calling __builtin_eh_return be built without optimizations, because the optimizer will then remove the spills. From: llvm-dev

I'm trying to figure out what this error message means: error: In RelAddr: Top-level forms in instruction pattern should have void types The definitions it's complaining about: //===----------------------------------------------------------------------===// // RELADDR //===----------------------------------------------------------------------===// def SDT_RELADDR :

Index: llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp =================================================================== --- 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: {

Hi Evan, first off thanks to you and Chris for taking time. On 6 Sep 2007, at 00:57, Evan Cheng wrote: > We'd like to see tail call optimization to be similar to the target > independent lowering of ISD::CALL nodes. These are auto-generated > from ???CallingConv.td files. Some target specific details such as > function address register (ECX in your example) should be coded in

Hi, all I am trying to add "not" instruction support to PTX backend. I add the line below in PTXInstrInfo.td, defm NOT : PTX_LOGIC<"not", not>; But I get errors below, ------------------------------------------------------------------------------- Included from PTX.td:75: PTXInstrInfo.td:732:10: error: Value 'PTX_LOGIC::opnode' of type 'SDNode' is

On 20 March 2014 02:09, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > I think this is just 2. It uses .eh_frame for unwinding proper. The > only difference in .eh_frame is that there is a personality function > defined. If there is no debug information, it should still be possible to unwind the stack via the saved LR on the stack, no? If there is only line info, you