This is an archive of the discontinued LLVM Phabricator instance.

Use iteration instead of recursion in CFIInserter
ClosedPublic

Authored by sanjoy on May 9 2018, 6:23 PM.

Diff Detail

Event Timeline

sanjoy created this revision.May 9 2018, 6:23 PM
dberris added a subscriber: dberris.May 9 2018, 6:36 PM
dberris added inline comments.
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?

sanjoy marked an inline comment as done.May 9 2018, 6:54 PM
sanjoy added inline comments.
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.

sanjoy updated this revision to Diff 146051.May 9 2018, 6:54 PM
  • Use SmallVector::append

@violetav can you take a look?

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.

Incoming offset/register values of each successor block should match outgoing offset/register values of its predecessors.

You're right, the propagation logic is wrong. I've rewritten the code to be clearer, and added the test case you mentioned.

sanjoy updated this revision to Diff 146153.May 10 2018, 10:33 AM
  • fix bug + test case
violetav added inline comments.May 11 2018, 7:01 AM
lib/CodeGen/CFIInstrInserter.cpp
250

You could add

if (SuccInfo.Processed) continue;

above this to avoid setting incoming values and pushing the block onto the stack multiple times.

294

Could you print out the function name as well? Seems it might be useful.

violetav accepted this revision.May 11 2018, 7:33 AM

LGTM, with these few nits, thanks!

This revision is now accepted and ready to land.May 11 2018, 7:33 AM
This revision was automatically updated to reflect the committed changes.