Go to the documentation of this file.
30 template <
class... Ts>
class PluginChain;
36 template <>
class PluginChain<> {
42 template <
class PluginT,
class... Ts>
43 class PluginChain<PluginT, Ts...> :
public PluginChain<Ts...> {
45 using Base = PluginChain<Ts...>;
49 : PluginChain<Ts...>(
F, TLI), Plugin(
F, TLI) {}
53 Plugin.run(Candidates);
63 using PluginChainFinal::PluginChainFinal;
72 std::vector<CandidateInfo>
74 std::vector<CandidateInfo> Result;
75 PImpl->get(Kind, Result);
This is an optimization pass for GlobalISel generic memory operations.
ValueProfileCollectorImpl inherits the API of PluginChainFinal.
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 n y store obj * new
decltype(auto) get(const PointerIntPair< PointerTy, IntBits, IntType, PtrTraits, Info > &Pair)
ValueProfileCollector(Function &Fn, TargetLibraryInfo &TLI)
Should compile to something r4 addze r3 instead we get
Provides information about what library functions are available for the current target.
std::vector< CandidateInfo > get(InstrProfValueKind Kind) const
returns a list of value profiling candidates of the given kind