Page MenuHomePhabricator

[NFC] Split logic of ImplicitControlFlowTracking to allow generalization
ClosedPublic

Authored by mkazantsev on Aug 20 2018, 12:46 AM.

Details

Summary

We have a class ImplicitControlFlowTracking which allows us to keep track of
instructions that can abnormally exit and answer queries like "whether or not
there is side-exiting instruction above this instruction in its block".

We may want to have the similar tracking for other types of "special" instructions,
for example instructions that write memory.

This patch separates ImplicitControlFlowTracking into two classes, isolating all
general logic not related to implicit control flow into its parent class. We can
later make another child of this class to keep track of instructions that write
memory.

The motivation for that is that we want to make these checks efficiently in the
patch https://reviews.llvm.org/D50891.

Diff Detail

Repository
rL LLVM

Event Timeline

mkazantsev created this revision.Aug 20 2018, 12:46 AM
fedor.sergeev accepted this revision.Aug 22 2018, 10:54 PM

'Precedence' seems to be a rather overloaded term. "Instruction precedence" seems to be sufficiently close to "operator precedence", so I would select a different term here.
Say, "InstructionFlowTracking".

Otherwise, LGTM.

include/llvm/Transforms/Utils/InstructionPrecedenceTracking.h
17 ↗(On Diff #161426)

This comment makes an impression that invalidation happens automatically.
Rephrase to something like "and to *manually* invalidate the cached data *after* the block's content has been changed".

This revision is now accepted and ready to land.Aug 22 2018, 10:54 PM
mkazantsev marked an inline comment as done.Aug 27 2018, 1:05 AM

I don't really like the name InstructionPrecedenceTracking, but other options don't sound good to mee too. I'm going to merge it as is (with comment fix) and just rename it in future when/if we find a better word for this.

This revision was automatically updated to reflect the committed changes.