Page MenuHomePhabricator

Adding code padding for performance stability - first policy (BranchesWithSameTargetAvoidancePolicy)
AbandonedPublic

Authored by opaparo on Jun 20 2017, 4:57 AM.

Details

Summary

This patch relies on an infrastructure introduced in a previous patch.

In the Intel Architectures Optimization Reference Manual, under the clause "Branch Prediction Optimization", the following optimization is suggested: "Avoid putting two conditional branch instructions in a loop so that both have the same branch target address and, at the same time, belong to (i.e.have their last bytes' addresses within) the same 16-byte aligned code block.".

In this patch a new policy is introduced. This new policy implements the above suggestion by inserting MCPaddingFragments before hazardous instructions (i.e. jmps whose target address is computable at compilation time) and returning positive penalty weight for 16 Byte windows that contain the said situation.

Diff Detail

Event Timeline

opaparo created this revision.Jun 20 2017, 4:57 AM
craig.topper added inline comments.Jun 21 2017, 2:01 PM
lib/Target/X86/MCTargetDesc/LLVMBuild.txt
22 ↗(On Diff #103185)

MC layer is not allowed to depend on CodeGen, Core or Target by explicit design requirements. llvm-mc does not want to link those libraries in.

What components do you need from these libraries?

opaparo added inline comments.Jun 26 2017, 6:17 AM
lib/Target/X86/MCTargetDesc/LLVMBuild.txt
22 ↗(On Diff #103185)

Thanks for the heads up. I'm using MachineBasicBlock, MachineFunction, MachineLoopInfo and TargetMachine in X86MCCodePadder for code padding related decisions.

I understand now why this is problematic and I am looking for ways to remove those dependencies.
By the way, are llvm component dependencies documented anywhere? Is there some sort of document listing them and stating what's allowed and what's not?

opaparo updated this revision to Diff 106198.Jul 12 2017, 6:49 AM

Removed unwanted dependencies introduces in my previous patch: MC layer no longer depends on CodeGen, Core or Target. This was achieved by introducing a new structure named MCCodePaddingContext that is being created by AsmPrinter and passed on to the MC layer (all the way to MCCodePadder). This replaces the direct use of TargetMachine, MachineBasicBlock, MachineFunction and MachineLoopInfo by the MCCodePadder.
Note: This time I used "svn diff -x -U999999" to create the patch, so comparison between this patch and the previous one may prove to be challenging (This had to be done for future work and review).

opaparo marked an inline comment as done.Jul 12 2017, 6:57 AM

Adding folks here with a strong interest in this. =]

gberry added a subscriber: gberry.Aug 16 2017, 1:35 PM
iteratee added inline comments.Aug 16 2017, 2:23 PM
lib/Target/X86/MCTargetDesc/X86MCCodePadder.cpp
37

Should this be a feature of TargetMachine so that this list doesn't go out of date?

Do you plan on doing something similar for the DSB decode cache issues that occasionally arise?
Specifically this: https://bugs.llvm.org/show_bug.cgi?id=5615

Do you plan on doing something similar for the DSB decode cache issues that occasionally arise?
Specifically this: https://bugs.llvm.org/show_bug.cgi?id=5615

Yes, I have implemented a MCCodePaddingPolicy that addresses this issue. I will upload that patch once the infrastructure is accepted and committed.

lib/Target/X86/MCTargetDesc/X86MCCodePadder.cpp
37

It should. I am working on that, will upload the patch ASAP.

opaparo abandoned this revision.Jan 18 2018, 3:02 AM