Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CodeGen] It is safe to ignore internal reads when sinking #88003

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

AtariDreams
Copy link
Contributor

Consider this:

By definition, a bundle operand has to maintain the exact order of the individual instructions anyway, which means an internal read register is defined in the same bundle, which determines if that register is a dependency, as defines is what tells RegUnits what registers prior to it are available. Because an internal read is defined as a register defined once and then used, the value does not change after use.

Flagging internal reads as dependent makes sense inside a vacuum. However, given that the bundle will ensure internal read dependencies are kept via keeping all instructions in the same order, then we can get away with, assuming the compiler respects the bundle semantics, not flagging the Machine Instruction as having a register dependency. Because the truth is, at worst instructions after the bundle will depend on whatever writes inside the bundle. Instructions outside the bundle do not change just because one of their operands was read prior.

So basically, because bundles are contiguous sequences of instructions, as long as they are kept contiguous, an internal read is safe to ignore because it will not change between the def and the read, and as long as the def does not change, it does not matter where the instructions are, assuming the other operands not defined in the bundle do not also change. Changes in the operands that are not defined in said bundle are not internal reads and are flagged as dependencies anyway.

Consider this:

By definition, a bundle operand has to maintain the exact order of the individual instructions anyway, which means an internal read register is defined in the same bundle, which determines if that register is a dependency, as defines is what tells RegUnits what registers prior to it are available. Because an internal read is defined as a register defined once and then used, the value does not change after use.

Flagging internal reads as dependent makes sense inside a vacuum. However, given that the bundle will ensure internal read dependencies are kept via keeping all instructions in the same order, then we can get away with, assuming the compiler respects the bundle semantics, not flagging the Machine Instruction as having a register dependency. Because the truth is, at worst instructions after the bundle will depend on whatever writes inside the bundle. Instructions outside the bundle do not change just because one of their operands was read prior.

So basically, because bundles are contiguous sequences of instructions, as long as they are kept contiguous, an internal read is safe to ignore because it will not change between the def and the read, and as long as the def does not change, it does not matter where the instructions are, assuming the other operands not defined in the bundle do not also change. Changes in the operands that are not defined in said bundle are not internal reads and are flagged as dependencies anyway.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant