It splits the login of actual instruction emission away from the logic
that figures out the appropriate sequence on.
AArch64ExpandPseudo::expandMOVImm. The new function
AArch64_IMM::expandMOVImm, which return the list of the instruction to
materialize the immediate constant, is implemented on a separated
unit because it will be used in a subsequent patch to optimize floating
point materialization.
Details
Diff Detail
Event Timeline
lib/Target/AArch64/AArch64ExpandPseudoInsts.cpp | ||
---|---|---|
122–127 | 5? | |
lib/Target/AArch64/MCTargetDesc/CMakeLists.txt | ||
5 ↗ | (On Diff #189174) | Probably shouldn't be in MCTargetDesc; just lib/Target/AArch64/ is fine. MCTargetDesc generally only contains code used by the assembler, and there isn't any AArch64 directive that would require the assembler to expand an immediate. |
Ping, only this refactor is missing review for my aarch64 fp materialization optimization.
lib/Target/AArch64/AArch64ExpandPseudoInsts.cpp | ||
---|---|---|
124 | Is LastItem supposed to be set somewhere? Why isn't it used for AArch64::ORRXri? |
lib/Target/AArch64/AArch64ExpandPseudoInsts.cpp | ||
---|---|---|
124 | It should be set for last item iteration, I will fix it. And my understanding why it is not set fo AArch64::ORRXri is the register used is always WZR/XZR. |
LGTM
lib/Target/AArch64/AArch64ExpandPseudoInsts.cpp | ||
---|---|---|
124 | Isn't the point here to try to preserve the "dead" flag? How is the operand related? But if this actually matches the existing behavior, we can leave it for now, and clean it up later. (If the destination is actually dead, there's a much simpler way to expand the instruction... by emitting nothing at all.) |
Is LastItem supposed to be set somewhere? Why isn't it used for AArch64::ORRXri?