LLVM  13.0.0git
Public Member Functions | List of all members
llvm::SpeculateAroundPHIsPass Struct Reference

This pass handles simple speculating of instructions around PHIs when doing so is profitable for a particular target despite duplicated instructions. More...

#include "llvm/Transforms/Scalar/SpeculateAroundPHIs.h"

Inheritance diagram for llvm::SpeculateAroundPHIsPass:
Inheritance graph
Collaboration diagram for llvm::SpeculateAroundPHIsPass:
Collaboration graph

Public Member Functions

PreservedAnalyses run (Function &F, FunctionAnalysisManager &AM)
 Run the pass over the function. More...

Additional Inherited Members

- Static Public Member Functions inherited from llvm::PassInfoMixin< SpeculateAroundPHIsPass >
static StringRef name ()
 Gets the name of the pass we are mixed into. More...

Detailed Description

This pass handles simple speculating of instructions around PHIs when doing so is profitable for a particular target despite duplicated instructions.

The motivating example are PHIs of constants which will require materializing the constants along each edge. If the PHI is used by an instruction where the target can materialize the constant as part of the instruction, it is profitable to speculate those instructions around the PHI node. This can reduce dynamic instruction count as well as decrease register pressure.

Consider this IR for example:

br i1 %flag, label %a, label %b
br label %exit
br label %exit
%p = phi i32 [ 7, %a ], [ 11, %b ]
%sum = add i32 %arg, %p
ret i32 %sum

To materialize the inputs to this PHI node may require an explicit instruction. For example, on x86 this would turn into something like

testq %eax, %eax
movl $7, %rNN
jne .L
movl $11, %rNN
addl %edi, %rNN
movl %rNN, %eax

When these constants can be folded directly into another instruction, it would be preferable to avoid the potential for register pressure (above we can easily avoid it, but that isn't always true) and simply duplicate the instruction using the PHI:

br i1 %flag, label %a, label %b
%sum.1 = add i32 %arg, 7
br label %exit
%sum.2 = add i32 %arg, 11
br label %exit
%p = phi i32 [ %sum.1, %a ], [ %sum.2, %b ]

Which will generate something like the following on x86:

testq %eax, %eax
addl $7, %edi
jne .L
addl $11, %edi

It is important to note that this pass is never intended to handle more complex cases where speculating around PHIs allows simplifications of the IR itself or other subsequent optimizations. Those can and should already be handled before this pass is ever run by a more powerful analysis that can reason about equivalences and common subexpressions. Classically, those cases would be handled by a GVN-powered PRE or similar transform. This pass, in contrast, is only interested in cases where despite no simplifications to the IR itself, speculation is faster to execute. The result of this is that the cost models which are appropriate to consider here are relatively simple ones around execution and codesize cost, without any need to consider simplifications or other transformations.

Definition at line 102 of file SpeculateAroundPHIs.h.

Member Function Documentation

◆ run()

PreservedAnalyses SpeculateAroundPHIsPass::run ( Function F,
FunctionAnalysisManager AM 

The documentation for this struct was generated from the following files:
Add support for conditional and other related patterns Instead eax eax je LBB16_2 eax edi eax movl eax
Definition: README.txt:145
Decimal Convert From to National Zoned Signed int_ppc_altivec_bcdcfno i1
Definition: README_P9.txt:147
to esp esp setne al movzbw ax esp setg cl movzbw cx cmove cx cl jne LBB1_2 esp ret(also really horrible code on ppc). This is due to the expand code for 64-bit compares. GCC produces multiple branches
into eax xorps xmm0 xmm0 eax xmm0 movl
Definition: README-SSE.txt:624
the resulting code requires compare and branches when and if * p
Definition: README.txt:396
=0.0 ? 0.0 :(a > 0.0 ? 1.0 :-1.0) a
Definition: README.txt:489
the resulting code requires compare and branches when and if the revised code is with conditional branches instead of More there is a byte word extend before each where there should be only and the condition codes are not remembered when the same two values are compared twice More LSR enhancements i8 and i32 load store addressing modes are identical int b
Definition: README.txt:418
Common register allocation spilling lr str ldr sxth r3 ldr mla r4 can lr mov lr str ldr sxth r3 mla r4 and then merge mul and lr str ldr sxth r3 mla r4 It also increase the likelihood the store may become dead bb27 Successors according to LLVM ID Predecessors according to mbb< bb27, 0x8b0a7c0 > Note ADDri is not a two address instruction its result reg1037 is an operand of the PHI node in bb76 and its operand reg1039 is the result of the PHI node We should treat it as a two address code and make sure the ADDri is scheduled after any node that reads reg1039 Use info(i.e. register scavenger) to assign it a free register to allow reuse the collector could move the objects and invalidate the derived pointer This is bad enough in the first but safe points can crop up unpredictably **array_addr i32
Definition: README.txt:122
@ add
Definition: ARMAddressingModes.h:39
into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret esp eax movdqa xmm0 xmm0 esp const ret align it should be movdqa xmm0 edi
Definition: README-SSE.txt:650
foo esp xmm0 movsd esp eax addl
Definition: README-FPStack.txt:80
constexpr double phi
Definition: MathExtras.h:71
declare void exit(i32) noreturn nounwind This compiles into
Definition: README.txt:1072
print Instructions which execute on loop entry
Definition: MustExecute.cpp:339