Extended Description

This is a clone of rdar://10318439 (for apple people), originally by Jakob Olesen. I am filing this llvm PR for reference:

When we lower LLVM IR invoke instructions to machine code, we should model the control flow more accurately.

Currently, we do this:

BB#1:
ADJCALLSTACKDOWN
%R0 = COPY %vreg0
%R1 = COPY %vreg1
CALL foo, %R0, %R1, ...
%vreg3 = COPY %R0 # Return value
ADJCALLSTACKUP

BB#2: # preds = BB#1
foo

BB#3: EH_LANDING_PAD #preds = BB#1
%R0 = MAGIC
%vreg7 = COPY %R0 # exception pointer
bar

This is inaccurate because the instructions in BB#1 are not executed on the exceptional edge to the landing pad BB#3. Currently, the register allocator has to jump through hoops to avoid inserting split/spill code after the CALL.

I propose a call instruction that is also a terminator:

BB#1:
ADJCALLSTACKDOWN
%R0 = COPY %vreg0
%R1 = COPY %vreg1
INVOKE foo, %R0, %R1, ...

BB#2: # preds = BB#1
#Live-in: %R0
%vreg3 = COPY %R0 # Return value
ADJCALLSTACKUP
foo

BB#3: EH_LANDING_PAD #preds = BB#1
#Live-in: %R0
%vreg7 = COPY %R0 # exception pointer
bar

This models the control flow around DWARF exceptions more accurately, and it handles the different 'return values' that show up in physical registers on the two edges from the INVOKE. The register allocator can stick to the standard rule of not inserting code after the first terminator.

Machine code verification also becomes easier. Currently we have a lot of trouble verifying exception CFGs because anything goes. With an invoke instruction, we could verify invariants like:

• A block terminated by an invoke has exactly one landing pad successor, and one fall-through successor.
• A landing pad has only invoke predecessors.