[llvm-bugs] [Bug 27659] New: Exception throwing Call instructions (invokes) should be terminator machine instructions.

[via llvm-bugs]

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: unassignedbugs at nondot.org
          Reporter: matze at braunis.de
                CC: llvm-bugs at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160505/b7649e81/attachment.html>