On Jul 26, 2011, at 11:00 PM, Chris Lattner wrote:> On Jul 26, 2011, at 4:16 AM, Bill Wendling wrote: > >> For those who are playing along, I've started on the exception handling rewrite following the document and comments from this thread: >> >> http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/041748.html >> >> The repositories are: >> >> http://llvm.org/svn/llvm-project/llvm/branches/exception-handling-rewrite >> http://llvm.org/svn/llvm-project/cfe/branches/exception-handling-rewrite >> >> Progress Report: >> >> I created the two new instructions: landingpad and resume. Hand-modified code can run through the assembler and disassembler and emit the same code. The verifier can verify basic properties of the landingpad instruction. > > Hi Bill, > > Any reason to do this on a branch? Why can't the patches go into mainline? >Hi Chris, Some of the changes (like the inliner changes) are going to break the old EH way of doing things. The front-ends will need to change over to the new EH scheme. And they won't want to change over until things are finished. It's a bit of a chicken-and-egg thing. I figured that doing this on a branch first and then outlining how to change the front-ends and/or create an Auto-upgrade tool would be the best course of action. -bw
On Jul 27, 2011, at 1:08 AM, Bill Wendling wrote:>>> Progress Report: >>> >>> I created the two new instructions: landingpad and resume. Hand-modified code can run through the assembler and disassembler and emit the same code. The verifier can verify basic properties of the landingpad instruction. >> >> Hi Bill, >> >> Any reason to do this on a branch? Why can't the patches go into mainline? >> > > Hi Chris, > > Some of the changes (like the inliner changes) are going to break the old EH way of doing things. The front-ends will need to change over to the new EH scheme. And they won't want to change over until things are finished. It's a bit of a chicken-and-egg thing. I figured that doing this on a branch first and then outlining how to change the front-ends and/or create an Auto-upgrade tool would be the best course of action.I would greatly prefer for you to implement the new instructions in mainline, and add the new inliner logic (under a flag if need-be). There should be no breakage for existing code until the frontends switch to generating the new EH stuff. This can also be done under a flag in clang for example. -Chris
On Jul 27, 2011, at 8:02 AM, Chris Lattner wrote:> On Jul 27, 2011, at 1:08 AM, Bill Wendling wrote: > >>>> Progress Report: >>>> >>>> I created the two new instructions: landingpad and resume. Hand-modified code can run through the assembler and disassembler and emit the same code. The verifier can verify basic properties of the landingpad instruction. >>> >>> Hi Bill, >>> >>> Any reason to do this on a branch? Why can't the patches go into mainline? >>> >> >> Hi Chris, >> >> Some of the changes (like the inliner changes) are going to break the old EH way of doing things. The front-ends will need to change over to the new EH scheme. And they won't want to change over until things are finished. It's a bit of a chicken-and-egg thing. I figured that doing this on a branch first and then outlining how to change the front-ends and/or create an Auto-upgrade tool would be the best course of action. > > I would greatly prefer for you to implement the new instructions in mainline, and add the new inliner logic (under a flag if need-be). There should be no breakage for existing code until the frontends switch to generating the new EH stuff. This can also be done under a flag in clang for example. >Okay. I'll see what I can do. -bw