https://llvm.org/bugs/show_bug.cgi?id=27659
Bug ID: 27659
Summary: Exception throwing Call instructions (invokes) should
be terminator machine instructions.
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: ma...@braunis.de
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
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.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
