[PATCH] D79794: Change the INLINEASM_BR MachineInstr to be a non-terminating instruction.

Matthias Braun via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Oct 4 13:40:44 PDT 2021


MatzeB added a comment.

> This is a general issue with "asm goto", not just with "asm goto with outputs". Someone could stomp on registers, memory, and the like and leap to BFE without the necessary COPY / SPILL instructions to clean things up. We skirt around some of these issues by saying that outputs aren't valid on the indirect branch.

Not sure I follow here... if someone stomps on registers in inline-asm (without declaring that in the inputs/outputs) then it's obviously a bug in the input and not something the compiler can fix.

> Any thoughts on how to fix this without regressing support for asm goto w/ outputs?

For the record: I am not advocating to revert any patches at this point; I am a obviously a year to late for the review and despite the asm-goto the same problem exists for exception control too. I just feel that we should be aware of what we are doing and call things by their name :)

So unless I am missing something here the whole problem is about terminator instructions producing values. Correct me if I am missing some other aspect of the discussion.

So about supporting outputs in terminator instructions: The tricky part is that regalloc typically expects to be able to place things behind the definition of a value (typically spills or COPYs). The reason this is tricky, is that for a terminator you are forced to place those things into the successor block(s) instead. Placing the operations into the successor blocks in turn can be tricky if the successors have multiple predecessor ("critical edges") because then we can end up executing the instructions wrongfully when coming from the other predecessors. So that would require to either be in a position to split the critical edges as needed or have the register allocator be robust enough to deal with spills/COPYs being executed in more situations than desired in case of critical edges. If I understand the asm-goto construct correctly, then the asm-labels have enough abstraction that breaking critical edges is always possible (you are forced to list all possible targets in the ASM instructions and the compiler could replace 1 block for another, and cannot jump to arbitrary computed destinations like asm-goto, right?).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79794/new/

https://reviews.llvm.org/D79794



More information about the llvm-commits mailing list