This recursive step can overflow the stack.
Details
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 17918 Build 17918: arc lint + arc unit
Event Timeline
lib/CodeGen/CFIInstrInserter.cpp | ||
---|---|---|
225–228 | Does this change the order of iteration here? It looks like because you're using a stack and going from the top of the stack, it's slightly different from the BFS nature of the recursion, no? Some questions: does it matter, and if it does, maybe use a queue? | |
237 | Consider using Stack.append(...) instead, to reduce the requirement for incrementally growing the stack? |
lib/CodeGen/CFIInstrInserter.cpp | ||
---|---|---|
225–228 | I didn't worry about this too much since no tests broke. Having said that, I don't know if it matters. In fact I don't know this code at all. I'm hoping the original authors will chime in with any inputs. |
Incoming offset/register values of each successor block should match outgoing offset/register values of its predecessors.
This change potentially won't set correct offset/register to indirect successors - you always set incoming values to all successors to be the outgoing values of the current block, which can turn out to be the same as outgoing values of their direct predecessor, but not necessarily. Consider this example:
# RUN: llc -o - %s -mtriple=x86_64-- -verify-cfiinstrs -run-pass=cfi-instr-inserter --- | define void @foo() { ret void } ... --- name: foo body: | bb.0: JE_1 %bb.3, implicit $eflags bb.1: CFI_INSTRUCTION def_cfa_offset 24 bb.2: CFI_INSTRUCTION def_cfa_offset 8 bb.3: RET 0 ...
bb2 will have incoming offset set to 8, from bb0, and not 24, from bb1.
You're right, the propagation logic is wrong. I've rewritten the code to be clearer, and added the test case you mentioned.
Does this change the order of iteration here? It looks like because you're using a stack and going from the top of the stack, it's slightly different from the BFS nature of the recursion, no?
Some questions: does it matter, and if it does, maybe use a queue?