This is an archive of the discontinued LLVM Phabricator instance.

[InstCombine] Fix change flag handling to report all IR changes up to the pass manager or preseved analyses
AbandonedPublic

Authored by craig.topper on Apr 4 2017, 2:05 PM.

Details

Summary

Currently InstCombine does not report dead code elimination or constant folding during the worklist building up to the pass manager or preserved analysis reporting. With one caveat, constant folding operands does report as a change and forces another iteration of the InstCombine pass. Since the return flag is currently based on iteration count being greater than 1, those modifications would be reported.

This patch adds a change flag to DCE and constant folding in the worklist build. Additionally we no longer treat changes during worklist building as a reason to run another iteration. Now the return value is based on a change flag instead of the iteration count.

Diff Detail

Event Timeline

craig.topper created this revision.Apr 4 2017, 2:05 PM
davide requested changes to this revision.Apr 9 2017, 3:35 PM

I assume this is a follow-up from our mailing list discussion. Not sure how feasible it is, but it would be great if you can leverage DebugCounters to maybe write a test. I'll appreciate if you can take a look. Thanks.

This revision now requires changes to proceed.Apr 9 2017, 3:35 PM

I can certainly try. What exactly were you envisioning?

chandlerc edited edge metadata.Apr 10 2017, 2:23 PM

I can certainly try. What exactly were you envisioning?

Alternatively or perhaps additionally, can you contrive a test case where we failed to invalidate an analysis but mutated the IR prior to this change? That seems like a good edge case test for the thing that would actually go wrong.

@chandlerc do you know of other tests that check this sort of thing or can you give more guidance. I haven't spent a lot of time in the IR optimizers until recently.

@chandlerc do you know of other tests that check this sort of thing or can you give more guidance. I haven't spent a lot of time in the IR optimizers until recently.

The closest is probably test/Transforms/Inline/cgscc-invalidate.ll. It's doing essentially the same thing but for the inliner. Unfortunately, it is much more complicated in some ways due to testing an interprocedural pass. The key is typically:

  1. compute some analysis
  2. run optimization pass that does mutation
  3. run verifier for analysis

If #3 gets a stale analysis it should fail. This means you need a verifier that will detect the old analysis as invalid after the mutation in #2. Then you want to write FileCheck patterns to verify that #2 actually *does* mutate the IR in the interesting way.

@chandlerc What analysis has a verifier that is sensitive to which instructions exist? If we delete any BasicBlocks I believe those do get reported up.

Err, we never delete basic blocks, we just remove all instructions from them if its unreachable.

craig.topper abandoned this revision.May 30 2017, 3:29 PM