search for: ip2state

Displaying 13 results from an estimated 13 matches for "ip2state".

Did you mean: apstate
2015 May 19
3
[LLVMdev] WinEH work to be done (in progress and otherwise)
...via the stack and everything would more or less fall into place. Now that I'm taking a closer look it also appears that live code must be generated to keep the EH state updated -- at least that appears to be what MSVC is doing. The live numbering of EH states is an interesting contrast to the ip2state table approach used in the x86_64 case, and it makes me wonder what complications would arise from trying to generate the EH state numbers in the front end. Reid's recent RFC mentioned that, "The natural scoping rules of C++ make it so that doing this numbering at the source level is triv...
2015 May 13
4
[LLVMdev] Extending AsmPrinterHandler
(background) The CoreCLR expects a JIT to produce a MSIL bytecode offset to code offset mapping annotated with a few extra bits denoting if it’s prolog/epilog, or it’s a call, or if there’s operands remaining on the MSIL virtual stack in some cases. Our initial prototype has the MSIL offset stashed in the line number field. We could stash the extra bits in the column info but that’s starting to
2015 May 19
0
[LLVMdev] WinEH work to be done (in progress and otherwise)
...ed -- at least that appears to be what MSVC is > doing. > Yep. Whatever numbering we do for 64-bit, we should reuse the same code to get the numbers and insert a bunch of stores in the IR. At least, that's the idea. > The live numbering of EH states is an interesting contrast to the ip2state > table approach used in the x86_64 case, and it makes me wonder what > complications would arise from trying to generate the EH state numbers in > the front end. Reid’s recent RFC mentioned that, “The natural scoping > rules of C++ make it so that doing this numbering at the source le...
2015 Jan 27
2
[LLVMdev] RFC: Native Windows C++ exception handling
I was thinking about this last night, and I came up with a third alternative which I think looks very promising. It’s basically a re-working of the previous alternative to use the landingpad concept rather than arbitrary fake logic, but it uses a single landing pad for the entire function that mimics the logic of the personality function to dispatch unwinding calls and catch handlers. I believe
2020 May 03
2
[RFC] [Windows SEH] Local_Unwind (Jumping out of a _finally)
..., machine basic block layout is very free-handed. Today, CodeGen puts labels around every potentially-throwing call, does block layout without considering try regions, and then collapses adjacent label regions with the same landingpad during AsmPrinting. For MSVC C++ EH, state number stores and the ip2state table achieve the same goal. [Ten] Yes, I saw that (pretty nice implementation actually). This design and implementation completely inherits current mechanism except that now it’s allowed to report EH state ranges that only contain memory/computation instructions (for obvious reason). I’m not su...
2015 Jan 29
0
[LLVMdev] RFC: Native Windows C++ exception handling
...the branch hint and rearrange to: callq g callq h testl global(%rip) jne .L1 .L2: callq h callq g .L1: callq i jmp .L2 Perhaps we can assign landing pads EH states during preparation by placing a call to something like @llvm.eh.state there, or making it part of the @llvm.eh.actions call? Then the ip2state table will assign the .L1 block the same state as the range over the h() calls. On Wed, Jan 28, 2015 at 4:49 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > Hi Reid, > > > > I’ve worked through a few scenarios, and I think this is converging. I’m > attaching a n...
2020 Apr 15
2
[RFC] [Windows SEH][-EHa] Support Hardware Exception Handling
..., machine basic block layout is very free-handed. Today, CodeGen puts labels around every potentially-throwing call, does block layout without considering try regions, and then collapses adjacent label regions with the same landingpad during AsmPrinting. For MSVC C++ EH, state number stores and the ip2state table achieve the same goal. [Ten] Yes, I saw that (pretty nice implementation actually). This design and implementation completely inherits current mechanism except that now it’s allowed to report EH state ranges that only contain memory/computation instructions (for obvious reason). I’m not su...
2020 Apr 01
2
[RFC] [Windows SEH] Local_Unwind (Jumping out of a _finally) and -EHa (Hardware Exception Handling)
Hi, all, The intend of this thread is to complete the support for Windows SEH. Currently there are two major missing features: Jumping out of a _finally and Hardware exception handling. The document below is my proposed design and implementation to fully support SEH on LLVM. I have completely implemented this design on a branch in repo:
2020 Apr 16
2
[RFC] [Windows SEH][-EHa] Support Hardware Exception Handling
..., machine basic block layout is very free-handed. Today, CodeGen puts labels around every potentially-throwing call, does block layout without considering try regions, and then collapses adjacent label regions with the same landingpad during AsmPrinting. For MSVC C++ EH, state number stores and the ip2state table achieve the same goal. [Ten] Yes, I saw that (pretty nice implementation actually). This design and implementation completely inherits current mechanism except that now it’s allowed to report EH state ranges that only contain memory/computation instructions (for obvious reason). I’m not su...
2015 Jan 27
2
[LLVMdev] RFC: Native Windows C++ exception handling
...was an assignment of a variable like 'x' before and after the call and a load of 'x' in the catch handlers? I don't think we can do correct phi insertion on the CFG as written. 3. Ultimately, the explicit state setting intrinsics will be lowered out and we will need to form the ip2state table. Unfortunately, bracketed intrinsics aren't quite enough to recover the natural scoping of the source program, which is something we've seen with @llvm.lifetime.start / end. What should the backend do if it sees control flow like this? bb0: call void @llvm.eh.setehstate(i32 0) br...
2015 May 18
4
[LLVMdev] New EH representation for MSVC compatibility
On Fri, May 15, 2015 at 5:27 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > I like the way this sorts out with regard to funclet code generation. > It feels very natural for Windows EH, though obviously not as natural for > non-Windows targets and I think it is likely to block some optimizations > that are currently possible with those targets. > Right, it will
2015 Jan 29
4
[LLVMdev] RFC: Native Windows C++ exception handling
Hi Reid, I’ve worked through a few scenarios, and I think this is converging. I’m attaching a new example, which extends the one we’ve been working through to handle a few more cases. I wasn’t sure what you intended the first i32 argument in an llvm.eh.actions entry to be. I’ve been using it as a place to store the eh state that I’m associating with the action, but that’s kind of circular
2020 Apr 16
2
[RFC] [Windows SEH][-EHa] Support Hardware Exception Handling
..., machine basic block layout is very free-handed. Today, CodeGen puts labels around every potentially-throwing call, does block layout without considering try regions, and then collapses adjacent label regions with the same landingpad during AsmPrinting. For MSVC C++ EH, state number stores and the ip2state table achieve the same goal. [Ten] Yes, I saw that (pretty nice implementation actually). This design and implementation completely inherits current mechanism except that now it’s allowed to report EH state ranges that only contain memory/computation instructions (for obvious reason). I’m not su...