2011-04-28 22:27:02 -08:00
|
|
|
//===- ScopHelper.cpp - Some Helper Functions for Scop. ------------------===//
|
|
|
|
|
//
|
2019-01-18 23:50:56 -09:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2011-04-28 22:27:02 -08:00
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
//
|
|
|
|
|
// Small functions that help with Scop and LLVM-IR.
|
|
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
#include "polly/Support/ScopHelper.h"
|
2015-10-01 15:45:51 -08:00
|
|
|
#include "polly/Options.h"
|
2013-04-16 00:04:42 -08:00
|
|
|
#include "polly/ScopInfo.h"
|
2015-10-09 15:40:24 -08:00
|
|
|
#include "polly/Support/SCEVValidator.h"
|
2011-04-28 22:27:02 -08:00
|
|
|
#include "llvm/Analysis/LoopInfo.h"
|
|
|
|
|
#include "llvm/Analysis/RegionInfo.h"
|
|
|
|
|
#include "llvm/Analysis/ScalarEvolution.h"
|
|
|
|
|
#include "llvm/Analysis/ScalarEvolutionExpressions.h"
|
2014-04-21 19:30:19 -08:00
|
|
|
#include "llvm/Transforms/Utils/BasicBlockUtils.h"
|
2021-03-15 09:13:21 -08:00
|
|
|
#include "llvm/Transforms/Utils/LoopUtils.h"
|
2020-05-20 03:21:06 -08:00
|
|
|
#include "llvm/Transforms/Utils/ScalarEvolutionExpander.h"
|
2023-01-02 18:18:46 -09:00
|
|
|
#include <optional>
|
2011-04-28 22:27:02 -08:00
|
|
|
|
|
|
|
|
using namespace llvm;
|
2015-08-18 03:56:00 -08:00
|
|
|
using namespace polly;
|
2011-04-28 22:27:02 -08:00
|
|
|
|
2014-04-21 19:30:19 -08:00
|
|
|
#define DEBUG_TYPE "polly-scop-helper"
|
|
|
|
|
|
2018-04-20 10:55:44 -08:00
|
|
|
static cl::list<std::string> DebugFunctions(
|
|
|
|
|
"polly-debug-func",
|
|
|
|
|
cl::desc("Allow calls to the specified functions in SCoPs even if their "
|
|
|
|
|
"side-effects are unknown. This can be used to do debug output in "
|
|
|
|
|
"Polly-transformed code."),
|
2022-06-04 23:31:44 -08:00
|
|
|
cl::Hidden, cl::CommaSeparated, cl::cat(PollyCategory));
|
2018-04-20 10:55:44 -08:00
|
|
|
|
2015-08-11 06:39:21 -08:00
|
|
|
// Ensures that there is just one predecessor to the entry node from outside the
|
|
|
|
|
// region.
|
|
|
|
|
// The identity of the region entry node is preserved.
|
|
|
|
|
static void simplifyRegionEntry(Region *R, DominatorTree *DT, LoopInfo *LI,
|
|
|
|
|
RegionInfo *RI) {
|
2014-09-10 06:50:23 -08:00
|
|
|
BasicBlock *EnteringBB = R->getEnteringBlock();
|
2015-08-11 06:39:21 -08:00
|
|
|
BasicBlock *Entry = R->getEntry();
|
2014-09-10 06:50:23 -08:00
|
|
|
|
2015-08-11 06:39:21 -08:00
|
|
|
// Before (one of):
|
|
|
|
|
//
|
|
|
|
|
// \ / //
|
|
|
|
|
// EnteringBB //
|
|
|
|
|
// | \------> //
|
|
|
|
|
// \ / | //
|
|
|
|
|
// Entry <--\ Entry <--\ //
|
|
|
|
|
// / \ / / \ / //
|
|
|
|
|
// .... .... //
|
2015-01-19 03:37:33 -09:00
|
|
|
|
2013-04-16 00:04:42 -08:00
|
|
|
// Create single entry edge if the region has multiple entry edges.
|
2014-09-10 06:50:23 -08:00
|
|
|
if (!EnteringBB) {
|
2015-08-11 06:39:21 -08:00
|
|
|
SmallVector<BasicBlock *, 4> Preds;
|
|
|
|
|
for (BasicBlock *P : predecessors(Entry))
|
|
|
|
|
if (!R->contains(P))
|
|
|
|
|
Preds.push_back(P);
|
|
|
|
|
|
|
|
|
|
BasicBlock *NewEntering =
|
|
|
|
|
SplitBlockPredecessors(Entry, Preds, ".region_entering", DT, LI);
|
|
|
|
|
|
|
|
|
|
if (RI) {
|
|
|
|
|
// The exit block of predecessing regions must be changed to NewEntering
|
|
|
|
|
for (BasicBlock *ExitPred : predecessors(NewEntering)) {
|
|
|
|
|
Region *RegionOfPred = RI->getRegionFor(ExitPred);
|
|
|
|
|
if (RegionOfPred->getExit() != Entry)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
while (!RegionOfPred->isTopLevelRegion() &&
|
|
|
|
|
RegionOfPred->getExit() == Entry) {
|
|
|
|
|
RegionOfPred->replaceExit(NewEntering);
|
|
|
|
|
RegionOfPred = RegionOfPred->getParent();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Make all ancestors use EnteringBB as entry; there might be edges to it
|
|
|
|
|
Region *AncestorR = R->getParent();
|
|
|
|
|
RI->setRegionFor(NewEntering, AncestorR);
|
|
|
|
|
while (!AncestorR->isTopLevelRegion() && AncestorR->getEntry() == Entry) {
|
|
|
|
|
AncestorR->replaceEntry(NewEntering);
|
|
|
|
|
AncestorR = AncestorR->getParent();
|
|
|
|
|
}
|
2014-09-15 10:34:45 -08:00
|
|
|
}
|
|
|
|
|
|
2015-08-11 06:39:21 -08:00
|
|
|
EnteringBB = NewEntering;
|
2013-04-16 00:04:42 -08:00
|
|
|
}
|
2015-08-11 06:39:21 -08:00
|
|
|
assert(R->getEnteringBlock() == EnteringBB);
|
2013-04-16 00:04:42 -08:00
|
|
|
|
2015-08-11 06:39:21 -08:00
|
|
|
// After:
|
|
|
|
|
//
|
|
|
|
|
// \ / //
|
|
|
|
|
// EnteringBB //
|
|
|
|
|
// | //
|
|
|
|
|
// | //
|
|
|
|
|
// Entry <--\ //
|
|
|
|
|
// / \ / //
|
|
|
|
|
// .... //
|
|
|
|
|
}
|
2014-09-15 10:34:45 -08:00
|
|
|
|
2015-08-11 06:39:21 -08:00
|
|
|
// Ensure that the region has a single block that branches to the exit node.
|
|
|
|
|
static void simplifyRegionExit(Region *R, DominatorTree *DT, LoopInfo *LI,
|
|
|
|
|
RegionInfo *RI) {
|
|
|
|
|
BasicBlock *ExitBB = R->getExit();
|
|
|
|
|
BasicBlock *ExitingBB = R->getExitingBlock();
|
|
|
|
|
|
|
|
|
|
// Before:
|
|
|
|
|
//
|
|
|
|
|
// (Region) ______/ //
|
|
|
|
|
// \ | / //
|
|
|
|
|
// ExitBB //
|
|
|
|
|
// / \ //
|
|
|
|
|
|
|
|
|
|
if (!ExitingBB) {
|
|
|
|
|
SmallVector<BasicBlock *, 4> Preds;
|
|
|
|
|
for (BasicBlock *P : predecessors(ExitBB))
|
|
|
|
|
if (R->contains(P))
|
|
|
|
|
Preds.push_back(P);
|
|
|
|
|
|
|
|
|
|
// Preds[0] Preds[1] otherBB //
|
|
|
|
|
// \ | ________/ //
|
|
|
|
|
// \ | / //
|
|
|
|
|
// BB //
|
|
|
|
|
ExitingBB =
|
|
|
|
|
SplitBlockPredecessors(ExitBB, Preds, ".region_exiting", DT, LI);
|
|
|
|
|
// Preds[0] Preds[1] otherBB //
|
|
|
|
|
// \ / / //
|
|
|
|
|
// BB.region_exiting / //
|
|
|
|
|
// \ / //
|
|
|
|
|
// BB //
|
|
|
|
|
|
|
|
|
|
if (RI)
|
|
|
|
|
RI->setRegionFor(ExitingBB, R);
|
|
|
|
|
|
|
|
|
|
// Change the exit of nested regions, but not the region itself,
|
|
|
|
|
R->replaceExitRecursive(ExitingBB);
|
|
|
|
|
R->replaceExit(ExitBB);
|
2013-04-16 00:04:42 -08:00
|
|
|
}
|
2015-08-11 06:39:21 -08:00
|
|
|
assert(ExitingBB == R->getExitingBlock());
|
|
|
|
|
|
|
|
|
|
// After:
|
|
|
|
|
//
|
|
|
|
|
// \ / //
|
|
|
|
|
// ExitingBB _____/ //
|
|
|
|
|
// \ / //
|
|
|
|
|
// ExitBB //
|
|
|
|
|
// / \ //
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void polly::simplifyRegion(Region *R, DominatorTree *DT, LoopInfo *LI,
|
|
|
|
|
RegionInfo *RI) {
|
|
|
|
|
assert(R && !R->isTopLevelRegion());
|
|
|
|
|
assert(!RI || RI == R->getRegionInfo());
|
|
|
|
|
assert((!RI || DT) &&
|
|
|
|
|
"RegionInfo requires DominatorTree to be updated as well");
|
2014-09-10 06:50:23 -08:00
|
|
|
|
2015-08-11 06:39:21 -08:00
|
|
|
simplifyRegionEntry(R, DT, LI, RI);
|
|
|
|
|
simplifyRegionExit(R, DT, LI, RI);
|
|
|
|
|
assert(R->isSimple());
|
2013-04-16 00:04:42 -08:00
|
|
|
}
|
|
|
|
|
|
2015-08-11 06:04:06 -08:00
|
|
|
// Split the block into two successive blocks.
|
|
|
|
|
//
|
|
|
|
|
// Like llvm::SplitBlock, but also preserves RegionInfo
|
2025-04-28 00:21:10 -08:00
|
|
|
static BasicBlock *splitBlock(BasicBlock *Old, BasicBlock::iterator SplitPt,
|
2015-08-11 06:04:06 -08:00
|
|
|
DominatorTree *DT, llvm::LoopInfo *LI,
|
|
|
|
|
RegionInfo *RI) {
|
2025-04-28 00:21:10 -08:00
|
|
|
assert(Old);
|
2015-08-11 06:04:06 -08:00
|
|
|
|
|
|
|
|
// Before:
|
|
|
|
|
//
|
|
|
|
|
// \ / //
|
|
|
|
|
// Old //
|
|
|
|
|
// / \ //
|
|
|
|
|
|
|
|
|
|
BasicBlock *NewBlock = llvm::SplitBlock(Old, SplitPt, DT, LI);
|
|
|
|
|
|
|
|
|
|
if (RI) {
|
|
|
|
|
Region *R = RI->getRegionFor(Old);
|
|
|
|
|
RI->setRegionFor(NewBlock, R);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// After:
|
|
|
|
|
//
|
|
|
|
|
// \ / //
|
|
|
|
|
// Old //
|
|
|
|
|
// | //
|
|
|
|
|
// NewBlock //
|
|
|
|
|
// / \ //
|
|
|
|
|
|
|
|
|
|
return NewBlock;
|
|
|
|
|
}
|
|
|
|
|
|
[Polly][PM][WIP] Polly pass registration
Summary:
This patch is a first attempt at registering Polly passes with the LLVM tools. Tool plugins are still unsupported, but this registration is usable from the tools if Polly is linked into them (albeit requiring minimal patches to those tools). Registration requires a small amount of machinery (the owning analysis proxies), necessary for injecting ScopAnalysisManager objects into the calling tools.
This patch is marked WIP because the registration is incomplete. Parsing manual pipelines is fully supported, but default pass injection into the O3 pipeline is lacking, mostly because there is opportunity for some redesign here, I believe. The first point of order would be insertion points. I think it makes sense to run before the vectorizers. Running Polly Early, however, is weird. Mostly because it actually is the default (which to me is unexpected), and because Polly runs it's own O1 pipeline. Why not instead insert it at an appropriate place somewhere after simplification happend? Running after the loop optimizers seems intuitive, but it also seems wasteful, since multiple consecutive loops might well be a single scop, and we don't need to run for all of them.
My second request for comments would be regarding all those smallish helper passes we have, like PollyViewer, PollyPrinter, PollyImportJScop. Right now these are controlled by command line options, deciding whether they should be part of the Polly pipeline. What is your opinion on treating them like real passes, and have the user write an appropriate pipeline if they want to use any of them?
Reviewers: grosser, Meinersbur, bollu
Reviewed By: grosser
Subscribers: llvm-commits, pollydev
Tags: #polly
Differential Revision: https://reviews.llvm.org/D35458
llvm-svn: 309826
2017-08-02 07:52:25 -08:00
|
|
|
void polly::splitEntryBlockForAlloca(BasicBlock *EntryBlock, DominatorTree *DT,
|
|
|
|
|
LoopInfo *LI, RegionInfo *RI) {
|
2017-06-08 04:06:15 -08:00
|
|
|
// Find first non-alloca instruction. Every basic block has a non-alloca
|
2011-04-28 22:27:02 -08:00
|
|
|
// instruction, as every well formed basic block has a terminator.
|
|
|
|
|
BasicBlock::iterator I = EntryBlock->begin();
|
2013-02-14 07:42:45 -09:00
|
|
|
while (isa<AllocaInst>(I))
|
|
|
|
|
++I;
|
2011-04-28 22:27:02 -08:00
|
|
|
|
[Polly][PM][WIP] Polly pass registration
Summary:
This patch is a first attempt at registering Polly passes with the LLVM tools. Tool plugins are still unsupported, but this registration is usable from the tools if Polly is linked into them (albeit requiring minimal patches to those tools). Registration requires a small amount of machinery (the owning analysis proxies), necessary for injecting ScopAnalysisManager objects into the calling tools.
This patch is marked WIP because the registration is incomplete. Parsing manual pipelines is fully supported, but default pass injection into the O3 pipeline is lacking, mostly because there is opportunity for some redesign here, I believe. The first point of order would be insertion points. I think it makes sense to run before the vectorizers. Running Polly Early, however, is weird. Mostly because it actually is the default (which to me is unexpected), and because Polly runs it's own O1 pipeline. Why not instead insert it at an appropriate place somewhere after simplification happend? Running after the loop optimizers seems intuitive, but it also seems wasteful, since multiple consecutive loops might well be a single scop, and we don't need to run for all of them.
My second request for comments would be regarding all those smallish helper passes we have, like PollyViewer, PollyPrinter, PollyImportJScop. Right now these are controlled by command line options, deciding whether they should be part of the Polly pipeline. What is your opinion on treating them like real passes, and have the user write an appropriate pipeline if they want to use any of them?
Reviewers: grosser, Meinersbur, bollu
Reviewed By: grosser
Subscribers: llvm-commits, pollydev
Tags: #polly
Differential Revision: https://reviews.llvm.org/D35458
llvm-svn: 309826
2017-08-02 07:52:25 -08:00
|
|
|
// splitBlock updates DT, LI and RI.
|
2025-04-28 00:21:10 -08:00
|
|
|
splitBlock(EntryBlock, I, DT, LI, RI);
|
[Polly][PM][WIP] Polly pass registration
Summary:
This patch is a first attempt at registering Polly passes with the LLVM tools. Tool plugins are still unsupported, but this registration is usable from the tools if Polly is linked into them (albeit requiring minimal patches to those tools). Registration requires a small amount of machinery (the owning analysis proxies), necessary for injecting ScopAnalysisManager objects into the calling tools.
This patch is marked WIP because the registration is incomplete. Parsing manual pipelines is fully supported, but default pass injection into the O3 pipeline is lacking, mostly because there is opportunity for some redesign here, I believe. The first point of order would be insertion points. I think it makes sense to run before the vectorizers. Running Polly Early, however, is weird. Mostly because it actually is the default (which to me is unexpected), and because Polly runs it's own O1 pipeline. Why not instead insert it at an appropriate place somewhere after simplification happend? Running after the loop optimizers seems intuitive, but it also seems wasteful, since multiple consecutive loops might well be a single scop, and we don't need to run for all of them.
My second request for comments would be regarding all those smallish helper passes we have, like PollyViewer, PollyPrinter, PollyImportJScop. Right now these are controlled by command line options, deciding whether they should be part of the Polly pipeline. What is your opinion on treating them like real passes, and have the user write an appropriate pipeline if they want to use any of them?
Reviewers: grosser, Meinersbur, bollu
Reviewed By: grosser
Subscribers: llvm-commits, pollydev
Tags: #polly
Differential Revision: https://reviews.llvm.org/D35458
llvm-svn: 309826
2017-08-02 07:52:25 -08:00
|
|
|
}
|
|
|
|
|
|
2020-01-19 13:50:01 -09:00
|
|
|
void polly::recordAssumption(polly::RecordedAssumptionsTy *RecordedAssumptions,
|
|
|
|
|
polly::AssumptionKind Kind, isl::set Set,
|
|
|
|
|
DebugLoc Loc, polly::AssumptionSign Sign,
|
[Polly] Track defined behavior for PHI predecessor computation.
ZoneAlgorithms's computePHI relies on being provided with consistent a
schedule to compute the statement prodecessors of a statement containing
PHINodes. Otherwise unexpected results such as PHI nodes with multiple
predecessors can occur which would result in problems in the
algorithms expecting consistent data.
In the added test case, statement instances are scrubbed from the
SCoP their execution would result in undefined behavior (Due to a nsw
overflow). As already being undefined behavior in LLVM-IR, neither
AssumedContext nor InvalidContext are updated, giving computePHI no
means to avoid these cases.
Intoduce a new SCoP property, the DefinedBehaviorContext, that among
the runtime-checked conditions, also tracks the assumptions not needing
a runtime check, in particular those affecting the assumed control flow.
This replaces the manual combination of the 3 other contexts that was
already done in computePHI and setNewAccessRelation. Currently, the only
additional assumption is that loop induction variables will nsw flag for
not wrap, but potentially more can be added. Use in
hasFeasibleRuntimeContext, isl::ast_build and gisting are other
potential uses.
To limit computational complexity, the DefinedBehaviorContext is not
availabe if it grows too large (atm hardcoded to 8 disjuncts).
Possible other fixes include bailing out in computePHI when
inconsistencies are detected, choose an arbitrary value for inconsistent
cases (since it is undefined behavior anyways), or make the code
receiving the result from ComputePHI handle inconsistent data. All of
them reduce the quality of implementation having to bail out more often
and disabling the ability to assert on actually wrong results.
This fixes llvm.org/PR48783.
2021-01-21 18:20:53 -09:00
|
|
|
BasicBlock *BB, bool RTC) {
|
2020-01-19 13:50:01 -09:00
|
|
|
if (RecordedAssumptions)
|
[Polly] Track defined behavior for PHI predecessor computation.
ZoneAlgorithms's computePHI relies on being provided with consistent a
schedule to compute the statement prodecessors of a statement containing
PHINodes. Otherwise unexpected results such as PHI nodes with multiple
predecessors can occur which would result in problems in the
algorithms expecting consistent data.
In the added test case, statement instances are scrubbed from the
SCoP their execution would result in undefined behavior (Due to a nsw
overflow). As already being undefined behavior in LLVM-IR, neither
AssumedContext nor InvalidContext are updated, giving computePHI no
means to avoid these cases.
Intoduce a new SCoP property, the DefinedBehaviorContext, that among
the runtime-checked conditions, also tracks the assumptions not needing
a runtime check, in particular those affecting the assumed control flow.
This replaces the manual combination of the 3 other contexts that was
already done in computePHI and setNewAccessRelation. Currently, the only
additional assumption is that loop induction variables will nsw flag for
not wrap, but potentially more can be added. Use in
hasFeasibleRuntimeContext, isl::ast_build and gisting are other
potential uses.
To limit computational complexity, the DefinedBehaviorContext is not
availabe if it grows too large (atm hardcoded to 8 disjuncts).
Possible other fixes include bailing out in computePHI when
inconsistencies are detected, choose an arbitrary value for inconsistent
cases (since it is undefined behavior anyways), or make the code
receiving the result from ComputePHI handle inconsistent data. All of
them reduce the quality of implementation having to bail out more often
and disabling the ability to assert on actually wrong results.
This fixes llvm.org/PR48783.
2021-01-21 18:20:53 -09:00
|
|
|
RecordedAssumptions->push_back({Kind, Sign, Set, Loc, BB, RTC});
|
2020-01-19 13:50:01 -09:00
|
|
|
}
|
|
|
|
|
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
/// ScopExpander generates IR the the value of a SCEV that represents a value
|
|
|
|
|
/// from a SCoP.
|
|
|
|
|
///
|
|
|
|
|
/// IMPORTANT: There are two ScalarEvolutions at play here. First, the SE that
|
|
|
|
|
/// was used to analyze the original SCoP (not actually referenced anywhere
|
|
|
|
|
/// here, but passed as argument to make the distinction clear). Second, GenSE
|
|
|
|
|
/// which is the SE for the function that the code is emitted into. SE and GenSE
|
|
|
|
|
/// may be different when the generated code is to be emitted into an outlined
|
|
|
|
|
/// function, e.g. for a parallel loop. That is, each SCEV is to be used only by
|
|
|
|
|
/// the SE that "owns" it and ScopExpander handles the translation between them.
|
|
|
|
|
/// The SCEVVisitor methods are only to be called on SCEVs of the original SE.
|
|
|
|
|
/// Their job is to create a new SCEV for GenSE. The nested SCEVExpander is to
|
|
|
|
|
/// be used only with SCEVs belonging to GenSE. Currently SCEVs do not store a
|
|
|
|
|
/// reference to the ScalarEvolution they belong to, so a mixup does not
|
|
|
|
|
/// immediately cause a crash but certainly is a violation of its interface.
|
|
|
|
|
///
|
2015-08-18 03:56:00 -08:00
|
|
|
/// The SCEVExpander will __not__ generate any code for an existing SDiv/SRem
|
|
|
|
|
/// instruction but just use it, if it is referenced as a SCEVUnknown. We want
|
|
|
|
|
/// however to generate new code if the instruction is in the analyzed region
|
|
|
|
|
/// and we generate code outside/in front of that region. Hence, we generate the
|
|
|
|
|
/// code for the SDiv/SRem operands in front of the analyzed region and then
|
|
|
|
|
/// create a new SDiv/SRem operation there too.
|
2022-05-17 07:55:27 -08:00
|
|
|
struct ScopExpander final : SCEVVisitor<ScopExpander, const SCEV *> {
|
2015-08-18 03:56:00 -08:00
|
|
|
friend struct SCEVVisitor<ScopExpander, const SCEV *>;
|
|
|
|
|
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
explicit ScopExpander(const Region &R, ScalarEvolution &SE, Function *GenFn,
|
2025-12-11 05:26:47 -09:00
|
|
|
ScalarEvolution &GenSE, const char *Name,
|
2026-03-13 08:23:06 -08:00
|
|
|
ValueMapT *VMap, polly::LoopToScevMapT *LoopMap,
|
2025-12-11 05:26:47 -09:00
|
|
|
BasicBlock *RTCBB)
|
|
|
|
|
: Expander(GenSE, Name, /*PreserveLCSSA=*/false), Name(Name), R(R),
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
VMap(VMap), LoopMap(LoopMap), RTCBB(RTCBB), GenSE(GenSE), GenFn(GenFn) {
|
|
|
|
|
}
|
|
|
|
|
|
2025-04-28 00:21:10 -08:00
|
|
|
Value *expandCodeFor(const SCEV *E, Type *Ty, BasicBlock::iterator IP) {
|
|
|
|
|
assert(isInGenRegion(&*IP) &&
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
"ScopExpander assumes to be applied to generated code region");
|
|
|
|
|
const SCEV *GenE = visit(E);
|
|
|
|
|
return Expander.expandCodeFor(GenE, Ty, IP);
|
2015-08-18 03:56:00 -08:00
|
|
|
}
|
|
|
|
|
|
2018-06-27 12:35:02 -08:00
|
|
|
const SCEV *visit(const SCEV *E) {
|
|
|
|
|
// Cache the expansion results for intermediate SCEV expressions. A SCEV
|
|
|
|
|
// expression can refer to an operand multiple times (e.g. "x*x), so
|
|
|
|
|
// a naive visitor takes exponential time.
|
|
|
|
|
if (SCEVCache.count(E))
|
|
|
|
|
return SCEVCache[E];
|
|
|
|
|
const SCEV *Result = SCEVVisitor::visit(E);
|
|
|
|
|
SCEVCache[E] = Result;
|
|
|
|
|
return Result;
|
|
|
|
|
}
|
|
|
|
|
|
2015-08-18 03:56:00 -08:00
|
|
|
private:
|
|
|
|
|
SCEVExpander Expander;
|
|
|
|
|
const char *Name;
|
|
|
|
|
const Region &R;
|
2015-09-30 08:52:03 -08:00
|
|
|
ValueMapT *VMap;
|
2026-03-13 08:23:06 -08:00
|
|
|
polly::LoopToScevMapT *LoopMap;
|
2016-11-02 14:32:23 -08:00
|
|
|
BasicBlock *RTCBB;
|
2018-06-27 12:35:02 -08:00
|
|
|
DenseMap<const SCEV *, const SCEV *> SCEVCache;
|
2015-08-18 03:56:00 -08:00
|
|
|
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
ScalarEvolution &GenSE;
|
|
|
|
|
Function *GenFn;
|
|
|
|
|
|
|
|
|
|
/// Is the instruction part of the original SCoP (in contrast to be located in
|
|
|
|
|
/// the code-generated region)?
|
|
|
|
|
bool isInOrigRegion(Instruction *Inst) {
|
|
|
|
|
Function *Fn = R.getEntry()->getParent();
|
|
|
|
|
bool isInOrigRegion = Inst->getFunction() == Fn && R.contains(Inst);
|
|
|
|
|
assert((isInOrigRegion || GenFn == Inst->getFunction()) &&
|
|
|
|
|
"Instruction expected to be either in the SCoP or the translated "
|
|
|
|
|
"region");
|
|
|
|
|
return isInOrigRegion;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool isInGenRegion(Instruction *Inst) { return !isInOrigRegion(Inst); }
|
|
|
|
|
|
2016-06-11 11:26:08 -08:00
|
|
|
const SCEV *visitGenericInst(const SCEVUnknown *E, Instruction *Inst,
|
2025-04-28 00:21:10 -08:00
|
|
|
BasicBlock::iterator IP) {
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
if (!Inst || isInGenRegion(Inst))
|
2016-06-11 11:26:08 -08:00
|
|
|
return E;
|
|
|
|
|
|
|
|
|
|
assert(!Inst->mayThrow() && !Inst->mayReadOrWriteMemory() &&
|
|
|
|
|
!isa<PHINode>(Inst));
|
|
|
|
|
|
|
|
|
|
auto *InstClone = Inst->clone();
|
|
|
|
|
for (auto &Op : Inst->operands()) {
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
assert(GenSE.isSCEVable(Op->getType()));
|
2024-12-13 02:29:32 -09:00
|
|
|
const SCEV *OpSCEV = GenSE.getSCEV(Op);
|
2016-06-11 11:26:08 -08:00
|
|
|
auto *OpClone = expandCodeFor(OpSCEV, Op->getType(), IP);
|
|
|
|
|
InstClone->replaceUsesOfWith(Op, OpClone);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
InstClone->setName(Name + Inst->getName());
|
2025-04-28 00:21:10 -08:00
|
|
|
InstClone->insertBefore(IP);
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
return GenSE.getSCEV(InstClone);
|
2016-06-11 11:26:08 -08:00
|
|
|
}
|
|
|
|
|
|
2015-08-18 03:56:00 -08:00
|
|
|
const SCEV *visitUnknown(const SCEVUnknown *E) {
|
2015-09-30 08:52:03 -08:00
|
|
|
|
|
|
|
|
// If a value mapping was given try if the underlying value is remapped.
|
2016-02-21 07:36:00 -09:00
|
|
|
Value *NewVal = VMap ? VMap->lookup(E->getValue()) : nullptr;
|
|
|
|
|
if (NewVal) {
|
2024-12-13 02:29:32 -09:00
|
|
|
const SCEV *NewE = GenSE.getSCEV(NewVal);
|
2016-02-21 07:36:00 -09:00
|
|
|
|
|
|
|
|
// While the mapped value might be different the SCEV representation might
|
|
|
|
|
// not be. To this end we will check before we go into recursion here.
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
// FIXME: SCEVVisitor must only visit SCEVs that belong to the original
|
|
|
|
|
// SE. This calls it on SCEVs that belong GenSE.
|
2016-02-21 07:36:00 -09:00
|
|
|
if (E != NewE)
|
|
|
|
|
return visit(NewE);
|
|
|
|
|
}
|
2015-09-30 08:52:03 -08:00
|
|
|
|
2015-08-18 03:56:00 -08:00
|
|
|
Instruction *Inst = dyn_cast<Instruction>(E->getValue());
|
2025-04-28 00:21:10 -08:00
|
|
|
BasicBlock::iterator IP;
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
if (Inst && isInGenRegion(Inst))
|
2025-04-28 00:21:10 -08:00
|
|
|
IP = Inst->getIterator();
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
else if (R.getEntry()->getParent() != GenFn) {
|
|
|
|
|
// RTCBB is in the original function, but we are generating for a
|
|
|
|
|
// subfunction so we cannot emit to RTCBB. Usually, we land here only
|
|
|
|
|
// because E->getValue() is not an instruction but a global or constant
|
|
|
|
|
// which do not need to emit anything.
|
2025-04-28 00:21:10 -08:00
|
|
|
IP = GenFn->getEntryBlock().getTerminator()->getIterator();
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
} else if (Inst && RTCBB->getParent() == Inst->getFunction())
|
2025-04-28 00:21:10 -08:00
|
|
|
IP = RTCBB->getTerminator()->getIterator();
|
2016-06-11 11:28:15 -08:00
|
|
|
else
|
2025-04-28 00:21:10 -08:00
|
|
|
IP = RTCBB->getParent()->getEntryBlock().getTerminator()->getIterator();
|
2016-06-11 11:28:15 -08:00
|
|
|
|
2017-02-01 01:12:09 -09:00
|
|
|
if (!Inst || (Inst->getOpcode() != Instruction::SRem &&
|
|
|
|
|
Inst->getOpcode() != Instruction::SDiv))
|
2016-06-11 11:28:15 -08:00
|
|
|
return visitGenericInst(E, Inst, IP);
|
2015-08-18 03:56:00 -08:00
|
|
|
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
const SCEV *LHSScev = GenSE.getSCEV(Inst->getOperand(0));
|
|
|
|
|
const SCEV *RHSScev = GenSE.getSCEV(Inst->getOperand(1));
|
2016-05-23 00:55:43 -08:00
|
|
|
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
if (!GenSE.isKnownNonZero(RHSScev))
|
|
|
|
|
RHSScev = GenSE.getUMaxExpr(RHSScev, GenSE.getConstant(E->getType(), 1));
|
2015-08-18 03:56:00 -08:00
|
|
|
|
2016-06-11 11:28:15 -08:00
|
|
|
Value *LHS = expandCodeFor(LHSScev, E->getType(), IP);
|
|
|
|
|
Value *RHS = expandCodeFor(RHSScev, E->getType(), IP);
|
2015-08-18 03:56:00 -08:00
|
|
|
|
2025-04-28 00:21:10 -08:00
|
|
|
Inst = BinaryOperator::Create((Instruction::BinaryOps)Inst->getOpcode(),
|
|
|
|
|
LHS, RHS, Inst->getName() + Name, IP);
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
return GenSE.getSCEV(Inst);
|
2015-08-18 03:56:00 -08:00
|
|
|
}
|
|
|
|
|
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
/// The following functions will just traverse the SCEV and rebuild it using
|
|
|
|
|
/// GenSE and the new operands returned by the traversal.
|
2015-08-18 03:56:00 -08:00
|
|
|
///
|
|
|
|
|
///{
|
|
|
|
|
const SCEV *visitConstant(const SCEVConstant *E) { return E; }
|
2023-03-02 03:23:52 -09:00
|
|
|
const SCEV *visitVScale(const SCEVVScale *E) { return E; }
|
2026-01-16 02:58:04 -09:00
|
|
|
const SCEV *visitPtrToAddrExpr(const SCEVPtrToAddrExpr *E) {
|
|
|
|
|
return GenSE.getPtrToAddrExpr(visit(E->getOperand()));
|
|
|
|
|
}
|
2015-08-18 03:56:00 -08:00
|
|
|
const SCEV *visitTruncateExpr(const SCEVTruncateExpr *E) {
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
return GenSE.getTruncateExpr(visit(E->getOperand()), E->getType());
|
2015-08-18 03:56:00 -08:00
|
|
|
}
|
|
|
|
|
const SCEV *visitZeroExtendExpr(const SCEVZeroExtendExpr *E) {
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
return GenSE.getZeroExtendExpr(visit(E->getOperand()), E->getType());
|
2015-08-18 03:56:00 -08:00
|
|
|
}
|
|
|
|
|
const SCEV *visitSignExtendExpr(const SCEVSignExtendExpr *E) {
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
return GenSE.getSignExtendExpr(visit(E->getOperand()), E->getType());
|
2015-08-18 03:56:00 -08:00
|
|
|
}
|
|
|
|
|
const SCEV *visitUDivExpr(const SCEVUDivExpr *E) {
|
2016-04-29 02:36:58 -08:00
|
|
|
auto *RHSScev = visit(E->getRHS());
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
if (!GenSE.isKnownNonZero(RHSScev))
|
|
|
|
|
RHSScev = GenSE.getUMaxExpr(RHSScev, GenSE.getConstant(E->getType(), 1));
|
|
|
|
|
return GenSE.getUDivExpr(visit(E->getLHS()), RHSScev);
|
2015-08-18 03:56:00 -08:00
|
|
|
}
|
|
|
|
|
const SCEV *visitAddExpr(const SCEVAddExpr *E) {
|
2026-03-13 08:23:06 -08:00
|
|
|
SmallVector<SCEVUse, 4> NewOps;
|
2015-08-18 03:56:00 -08:00
|
|
|
for (const SCEV *Op : E->operands())
|
|
|
|
|
NewOps.push_back(visit(Op));
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
return GenSE.getAddExpr(NewOps);
|
2015-08-18 03:56:00 -08:00
|
|
|
}
|
|
|
|
|
const SCEV *visitMulExpr(const SCEVMulExpr *E) {
|
2026-03-13 08:23:06 -08:00
|
|
|
SmallVector<SCEVUse, 4> NewOps;
|
2015-08-18 03:56:00 -08:00
|
|
|
for (const SCEV *Op : E->operands())
|
|
|
|
|
NewOps.push_back(visit(Op));
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
return GenSE.getMulExpr(NewOps);
|
2015-08-18 03:56:00 -08:00
|
|
|
}
|
|
|
|
|
const SCEV *visitUMaxExpr(const SCEVUMaxExpr *E) {
|
2026-03-13 08:23:06 -08:00
|
|
|
SmallVector<SCEVUse, 4> NewOps;
|
|
|
|
|
for (SCEVUse Op : E->operands())
|
2015-08-18 03:56:00 -08:00
|
|
|
NewOps.push_back(visit(Op));
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
return GenSE.getUMaxExpr(NewOps);
|
2015-08-18 03:56:00 -08:00
|
|
|
}
|
|
|
|
|
const SCEV *visitSMaxExpr(const SCEVSMaxExpr *E) {
|
2026-03-13 08:23:06 -08:00
|
|
|
SmallVector<SCEVUse, 4> NewOps;
|
|
|
|
|
for (SCEVUse Op : E->operands())
|
2015-08-18 03:56:00 -08:00
|
|
|
NewOps.push_back(visit(Op));
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
return GenSE.getSMaxExpr(NewOps);
|
2015-08-18 03:56:00 -08:00
|
|
|
}
|
2019-05-08 02:36:04 -08:00
|
|
|
const SCEV *visitUMinExpr(const SCEVUMinExpr *E) {
|
2026-03-13 08:23:06 -08:00
|
|
|
SmallVector<SCEVUse, 4> NewOps;
|
|
|
|
|
for (SCEVUse Op : E->operands())
|
2019-05-08 02:36:04 -08:00
|
|
|
NewOps.push_back(visit(Op));
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
return GenSE.getUMinExpr(NewOps);
|
2019-05-08 02:36:04 -08:00
|
|
|
}
|
|
|
|
|
const SCEV *visitSMinExpr(const SCEVSMinExpr *E) {
|
2026-03-13 08:23:06 -08:00
|
|
|
SmallVector<SCEVUse, 4> NewOps;
|
|
|
|
|
for (SCEVUse Op : E->operands())
|
2019-05-08 02:36:04 -08:00
|
|
|
NewOps.push_back(visit(Op));
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
return GenSE.getSMinExpr(NewOps);
|
2019-05-08 02:36:04 -08:00
|
|
|
}
|
[SCEV] Sequential/in-order `UMin` expression
As discussed in https://github.com/llvm/llvm-project/issues/53020 / https://reviews.llvm.org/D116692,
SCEV is forbidden from reasoning about 'backedge taken count'
if the branch condition is a poison-safe logical operation,
which is conservatively correct, but is severely limiting.
Instead, we should have a way to express those
poison blocking properties in SCEV expressions.
The proposed semantics is:
```
Sequential/in-order min/max SCEV expressions are non-commutative variants
of commutative min/max SCEV expressions. If none of their operands
are poison, then they are functionally equivalent, otherwise,
if the operand that represents the saturation point* of given expression,
comes before the first poison operand, then the whole expression is not poison,
but is said saturation point.
```
* saturation point - the maximal/minimal possible integer value for the given type
The lowering is straight-forward:
```
compare each operand to the saturation point,
perform sequential in-order logical-or (poison-safe!) ordered reduction
over those checks, and if reduction returned true then return
saturation point else return the naive min/max reduction over the operands
```
https://alive2.llvm.org/ce/z/Q7jxvH (2 ops)
https://alive2.llvm.org/ce/z/QCRrhk (3 ops)
Note that we don't need to check the last operand: https://alive2.llvm.org/ce/z/abvHQS
Note that this is not commutative: https://alive2.llvm.org/ce/z/FK9e97
That allows us to handle the patterns in question.
Reviewed By: nikic, reames
Differential Revision: https://reviews.llvm.org/D116766
2022-01-10 08:49:41 -09:00
|
|
|
const SCEV *visitSequentialUMinExpr(const SCEVSequentialUMinExpr *E) {
|
2026-03-13 08:23:06 -08:00
|
|
|
SmallVector<SCEVUse, 4> NewOps;
|
|
|
|
|
for (SCEVUse Op : E->operands())
|
[SCEV] Sequential/in-order `UMin` expression
As discussed in https://github.com/llvm/llvm-project/issues/53020 / https://reviews.llvm.org/D116692,
SCEV is forbidden from reasoning about 'backedge taken count'
if the branch condition is a poison-safe logical operation,
which is conservatively correct, but is severely limiting.
Instead, we should have a way to express those
poison blocking properties in SCEV expressions.
The proposed semantics is:
```
Sequential/in-order min/max SCEV expressions are non-commutative variants
of commutative min/max SCEV expressions. If none of their operands
are poison, then they are functionally equivalent, otherwise,
if the operand that represents the saturation point* of given expression,
comes before the first poison operand, then the whole expression is not poison,
but is said saturation point.
```
* saturation point - the maximal/minimal possible integer value for the given type
The lowering is straight-forward:
```
compare each operand to the saturation point,
perform sequential in-order logical-or (poison-safe!) ordered reduction
over those checks, and if reduction returned true then return
saturation point else return the naive min/max reduction over the operands
```
https://alive2.llvm.org/ce/z/Q7jxvH (2 ops)
https://alive2.llvm.org/ce/z/QCRrhk (3 ops)
Note that we don't need to check the last operand: https://alive2.llvm.org/ce/z/abvHQS
Note that this is not commutative: https://alive2.llvm.org/ce/z/FK9e97
That allows us to handle the patterns in question.
Reviewed By: nikic, reames
Differential Revision: https://reviews.llvm.org/D116766
2022-01-10 08:49:41 -09:00
|
|
|
NewOps.push_back(visit(Op));
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
return GenSE.getUMinExpr(NewOps, /*Sequential=*/true);
|
[SCEV] Sequential/in-order `UMin` expression
As discussed in https://github.com/llvm/llvm-project/issues/53020 / https://reviews.llvm.org/D116692,
SCEV is forbidden from reasoning about 'backedge taken count'
if the branch condition is a poison-safe logical operation,
which is conservatively correct, but is severely limiting.
Instead, we should have a way to express those
poison blocking properties in SCEV expressions.
The proposed semantics is:
```
Sequential/in-order min/max SCEV expressions are non-commutative variants
of commutative min/max SCEV expressions. If none of their operands
are poison, then they are functionally equivalent, otherwise,
if the operand that represents the saturation point* of given expression,
comes before the first poison operand, then the whole expression is not poison,
but is said saturation point.
```
* saturation point - the maximal/minimal possible integer value for the given type
The lowering is straight-forward:
```
compare each operand to the saturation point,
perform sequential in-order logical-or (poison-safe!) ordered reduction
over those checks, and if reduction returned true then return
saturation point else return the naive min/max reduction over the operands
```
https://alive2.llvm.org/ce/z/Q7jxvH (2 ops)
https://alive2.llvm.org/ce/z/QCRrhk (3 ops)
Note that we don't need to check the last operand: https://alive2.llvm.org/ce/z/abvHQS
Note that this is not commutative: https://alive2.llvm.org/ce/z/FK9e97
That allows us to handle the patterns in question.
Reviewed By: nikic, reames
Differential Revision: https://reviews.llvm.org/D116766
2022-01-10 08:49:41 -09:00
|
|
|
}
|
2015-08-18 03:56:00 -08:00
|
|
|
const SCEV *visitAddRecExpr(const SCEVAddRecExpr *E) {
|
2026-03-13 08:23:06 -08:00
|
|
|
SmallVector<SCEVUse, 4> NewOps;
|
|
|
|
|
for (SCEVUse Op : E->operands())
|
2015-08-18 03:56:00 -08:00
|
|
|
NewOps.push_back(visit(Op));
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
|
|
|
|
|
const Loop *L = E->getLoop();
|
|
|
|
|
const SCEV *GenLRepl = LoopMap ? LoopMap->lookup(L) : nullptr;
|
|
|
|
|
if (!GenLRepl)
|
|
|
|
|
return GenSE.getAddRecExpr(NewOps, L, E->getNoWrapFlags());
|
|
|
|
|
|
|
|
|
|
// evaluateAtIteration replaces the SCEVAddrExpr with a direct calculation.
|
|
|
|
|
const SCEV *Evaluated =
|
|
|
|
|
SCEVAddRecExpr::evaluateAtIteration(NewOps, GenLRepl, GenSE);
|
|
|
|
|
|
|
|
|
|
// FIXME: This emits a SCEV for GenSE (since GenLRepl will refer to the
|
|
|
|
|
// induction variable of a generated loop), so we should not use SCEVVisitor
|
[Polly] Fix typos discovered by codespell (#124545)
Patch created using the following command line:
```bash
codespell polly --skip="*.pdf,polly/lib/External/*" --write-changes \
--ignore-words-list=couter,createor,distribues,doble,identty,indention,indx,olt,ore,padd,sais,te,theses
```
2025-01-27 06:18:47 -09:00
|
|
|
// with it. However, it still contains references to the SCoP region.
|
2026-07-13 02:40:53 -08:00
|
|
|
//
|
|
|
|
|
// Insert in the cache to cut recursive cycles:
|
|
|
|
|
// visitUnknown follow VMap and GenSE.getSCEV() back to E.
|
|
|
|
|
SCEVCache[E] = Evaluated;
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
return visit(Evaluated);
|
2015-08-18 03:56:00 -08:00
|
|
|
}
|
|
|
|
|
///}
|
|
|
|
|
};
|
|
|
|
|
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
Value *polly::expandCodeFor(Scop &S, llvm::ScalarEvolution &SE,
|
|
|
|
|
llvm::Function *GenFn, ScalarEvolution &GenSE,
|
|
|
|
|
const DataLayout &DL, const char *Name,
|
2025-04-28 00:21:10 -08:00
|
|
|
const SCEV *E, Type *Ty, BasicBlock::iterator IP,
|
[Polly] Use separate DT/LI/SE for outlined subfn. NFC. (#102460)
DominatorTree, LoopInfo, and ScalarEvolution are function-level analyses
that expect to be called only on instructions and basic blocks of the
function they were original created for. When Polly outlined a parallel
loop body into a separate function, it reused the same analyses seemed
to work until new checks to be added in #101198.
This patch creates new analyses for the subfunctions. GenDT, GenLI, and
GenSE now refer to the analyses of the current region of code. Outside
of an outlined function, they refer to the same analysis as used for the
SCoP, but are substituted within an outlined function.
Additionally to the cross-function queries of DT/LI/SE, we must not
create SCEVs that refer to a mix of expressions for old and generated
values. Currently, SCEVs themselves do not "remember" which
ScalarEvolution analysis they were created for, but mixing them is just
as unexpected as using DT/LI across function boundaries. Hence
`SCEVLoopAddRecRewriter` was combined into `ScopExpander`.
`SCEVLoopAddRecRewriter` only replaced induction variables but left
SCEVUnknowns to reference the old function. `SCEVParameterRewriter`
would have done so but its job was effectively superseded by
`ScopExpander`, and now also `SCEVLoopAddRecRewriter`. Some issues
persist put marked with a FIXME in the code. Changing them would
possibly cause this patch to be not NFC anymore.
2024-08-10 04:25:15 -08:00
|
|
|
ValueMapT *VMap, LoopToScevMapT *LoopMap,
|
2016-11-02 14:32:23 -08:00
|
|
|
BasicBlock *RTCBB) {
|
2025-12-11 05:26:47 -09:00
|
|
|
ScopExpander Expander(S.getRegion(), SE, GenFn, GenSE, Name, VMap, LoopMap,
|
|
|
|
|
RTCBB);
|
2015-08-18 03:56:00 -08:00
|
|
|
return Expander.expandCodeFor(E, Ty, IP);
|
|
|
|
|
}
|
2015-09-10 09:51:27 -08:00
|
|
|
|
2019-07-17 13:42:39 -08:00
|
|
|
Loop *polly::getLoopSurroundingScop(Scop &S, LoopInfo &LI) {
|
|
|
|
|
// Start with the smallest loop containing the entry and expand that
|
|
|
|
|
// loop until it contains all blocks in the region. If there is a loop
|
|
|
|
|
// containing all blocks in the region check if it is itself contained
|
|
|
|
|
// and if so take the parent loop as it will be the smallest containing
|
|
|
|
|
// the region but not contained by it.
|
|
|
|
|
Loop *L = LI.getLoopFor(S.getEntry());
|
|
|
|
|
while (L) {
|
|
|
|
|
bool AllContained = true;
|
|
|
|
|
for (auto *BB : S.blocks())
|
|
|
|
|
AllContained &= L->contains(BB);
|
|
|
|
|
if (AllContained)
|
|
|
|
|
break;
|
|
|
|
|
L = L->getParentLoop();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return L ? (S.contains(L) ? L->getParentLoop() : L) : nullptr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
unsigned polly::getNumBlocksInLoop(Loop *L) {
|
|
|
|
|
unsigned NumBlocks = L->getNumBlocks();
|
|
|
|
|
SmallVector<BasicBlock *, 4> ExitBlocks;
|
|
|
|
|
L->getExitBlocks(ExitBlocks);
|
|
|
|
|
|
|
|
|
|
for (auto ExitBlock : ExitBlocks) {
|
|
|
|
|
if (isa<UnreachableInst>(ExitBlock->getTerminator()))
|
|
|
|
|
NumBlocks++;
|
|
|
|
|
}
|
|
|
|
|
return NumBlocks;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
unsigned polly::getNumBlocksInRegionNode(RegionNode *RN) {
|
|
|
|
|
if (!RN->isSubRegion())
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
|
|
Region *R = RN->getNodeAs<Region>();
|
|
|
|
|
return std::distance(R->block_begin(), R->block_end());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Loop *polly::getRegionNodeLoop(RegionNode *RN, LoopInfo &LI) {
|
|
|
|
|
if (!RN->isSubRegion()) {
|
|
|
|
|
BasicBlock *BB = RN->getNodeAs<BasicBlock>();
|
|
|
|
|
Loop *L = LI.getLoopFor(BB);
|
|
|
|
|
|
|
|
|
|
// Unreachable statements are not considered to belong to a LLVM loop, as
|
|
|
|
|
// they are not part of an actual loop in the control flow graph.
|
|
|
|
|
// Nevertheless, we handle certain unreachable statements that are common
|
|
|
|
|
// when modeling run-time bounds checks as being part of the loop to be
|
|
|
|
|
// able to model them and to later eliminate the run-time bounds checks.
|
|
|
|
|
//
|
|
|
|
|
// Specifically, for basic blocks that terminate in an unreachable and
|
|
|
|
|
// where the immediate predecessor is part of a loop, we assume these
|
|
|
|
|
// basic blocks belong to the loop the predecessor belongs to. This
|
|
|
|
|
// allows us to model the following code.
|
|
|
|
|
//
|
|
|
|
|
// for (i = 0; i < N; i++) {
|
|
|
|
|
// if (i > 1024)
|
|
|
|
|
// abort(); <- this abort might be translated to an
|
|
|
|
|
// unreachable
|
|
|
|
|
//
|
|
|
|
|
// A[i] = ...
|
|
|
|
|
// }
|
|
|
|
|
if (!L && isa<UnreachableInst>(BB->getTerminator()) && BB->getPrevNode())
|
|
|
|
|
L = LI.getLoopFor(BB->getPrevNode());
|
|
|
|
|
return L;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Region *NonAffineSubRegion = RN->getNodeAs<Region>();
|
|
|
|
|
Loop *L = LI.getLoopFor(NonAffineSubRegion->getEntry());
|
|
|
|
|
while (L && NonAffineSubRegion->contains(L))
|
|
|
|
|
L = L->getParentLoop();
|
|
|
|
|
return L;
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-28 23:29:45 -08:00
|
|
|
static bool hasVariantIndex(GetElementPtrInst *Gep, Loop *L, Region &R,
|
|
|
|
|
ScalarEvolution &SE) {
|
|
|
|
|
for (const Use &Val : llvm::drop_begin(Gep->operands(), 1)) {
|
|
|
|
|
const SCEV *PtrSCEV = SE.getSCEVAtScope(Val, L);
|
|
|
|
|
Loop *OuterLoop = R.outermostLoopInRegion(L);
|
|
|
|
|
if (!SE.isLoopInvariant(PtrSCEV, OuterLoop))
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2015-10-07 12:17:36 -08:00
|
|
|
bool polly::isHoistableLoad(LoadInst *LInst, Region &R, LoopInfo &LI,
|
2018-06-28 23:29:45 -08:00
|
|
|
ScalarEvolution &SE, const DominatorTree &DT,
|
|
|
|
|
const InvariantLoadsSetTy &KnownInvariantLoads) {
|
2015-10-07 12:17:36 -08:00
|
|
|
Loop *L = LI.getLoopFor(LInst->getParent());
|
2016-11-17 13:25:17 -09:00
|
|
|
auto *Ptr = LInst->getPointerOperand();
|
2018-06-28 23:29:45 -08:00
|
|
|
|
|
|
|
|
// A LoadInst is hoistable if the address it is loading from is also
|
|
|
|
|
// invariant; in this case: another invariant load (whether that address
|
|
|
|
|
// is also not written to has to be checked separately)
|
|
|
|
|
// TODO: This only checks for a LoadInst->GetElementPtrInst->LoadInst
|
|
|
|
|
// pattern generated by the Chapel frontend, but generally this applies
|
|
|
|
|
// for any chain of instruction that does not also depend on any
|
|
|
|
|
// induction variable
|
|
|
|
|
if (auto *GepInst = dyn_cast<GetElementPtrInst>(Ptr)) {
|
|
|
|
|
if (!hasVariantIndex(GepInst, L, R, SE)) {
|
|
|
|
|
if (auto *DecidingLoad =
|
|
|
|
|
dyn_cast<LoadInst>(GepInst->getPointerOperand())) {
|
|
|
|
|
if (KnownInvariantLoads.count(DecidingLoad))
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-11-17 13:25:17 -09:00
|
|
|
const SCEV *PtrSCEV = SE.getSCEVAtScope(Ptr, L);
|
2015-10-07 12:17:36 -08:00
|
|
|
while (L && R.contains(L)) {
|
|
|
|
|
if (!SE.isLoopInvariant(PtrSCEV, L))
|
|
|
|
|
return false;
|
|
|
|
|
L = L->getParentLoop();
|
|
|
|
|
}
|
|
|
|
|
|
2025-05-07 22:00:09 -08:00
|
|
|
if (!Ptr->hasUseList())
|
|
|
|
|
return true;
|
|
|
|
|
|
2016-11-17 13:25:17 -09:00
|
|
|
for (auto *User : Ptr->users()) {
|
|
|
|
|
auto *UserI = dyn_cast<Instruction>(User);
|
2024-12-30 21:27:34 -09:00
|
|
|
if (!UserI || UserI->getFunction() != LInst->getFunction() ||
|
|
|
|
|
!R.contains(UserI))
|
2016-11-17 13:25:17 -09:00
|
|
|
continue;
|
|
|
|
|
if (!UserI->mayWriteToMemory())
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
auto &BB = *UserI->getParent();
|
2016-12-01 02:10:45 -09:00
|
|
|
if (DT.dominates(&BB, LInst->getParent()))
|
|
|
|
|
return false;
|
|
|
|
|
|
2016-11-17 13:25:17 -09:00
|
|
|
bool DominatesAllPredecessors = true;
|
2017-11-30 04:06:10 -09:00
|
|
|
if (R.isTopLevelRegion()) {
|
|
|
|
|
for (BasicBlock &I : *R.getEntry()->getParent())
|
|
|
|
|
if (isa<ReturnInst>(I.getTerminator()) && !DT.dominates(&BB, &I))
|
|
|
|
|
DominatesAllPredecessors = false;
|
|
|
|
|
} else {
|
|
|
|
|
for (auto Pred : predecessors(R.getExit()))
|
|
|
|
|
if (R.contains(Pred) && !DT.dominates(&BB, Pred))
|
|
|
|
|
DominatesAllPredecessors = false;
|
|
|
|
|
}
|
2016-11-17 13:25:17 -09:00
|
|
|
|
|
|
|
|
if (!DominatesAllPredecessors)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2015-10-07 12:17:36 -08:00
|
|
|
return true;
|
|
|
|
|
}
|
2015-10-09 15:40:24 -08:00
|
|
|
|
|
|
|
|
bool polly::isIgnoredIntrinsic(const Value *V) {
|
|
|
|
|
if (auto *IT = dyn_cast<IntrinsicInst>(V)) {
|
|
|
|
|
switch (IT->getIntrinsicID()) {
|
|
|
|
|
// Lifetime markers are supported/ignored.
|
|
|
|
|
case llvm::Intrinsic::lifetime_start:
|
|
|
|
|
case llvm::Intrinsic::lifetime_end:
|
|
|
|
|
// Invariant markers are supported/ignored.
|
|
|
|
|
case llvm::Intrinsic::invariant_start:
|
|
|
|
|
case llvm::Intrinsic::invariant_end:
|
|
|
|
|
// Some misc annotations are supported/ignored.
|
|
|
|
|
case llvm::Intrinsic::var_annotation:
|
|
|
|
|
case llvm::Intrinsic::ptr_annotation:
|
|
|
|
|
case llvm::Intrinsic::annotation:
|
|
|
|
|
case llvm::Intrinsic::donothing:
|
|
|
|
|
case llvm::Intrinsic::assume:
|
2017-06-08 04:06:15 -08:00
|
|
|
// Some debug info intrinsics are supported/ignored.
|
2015-10-09 15:40:24 -08:00
|
|
|
case llvm::Intrinsic::dbg_value:
|
|
|
|
|
case llvm::Intrinsic::dbg_declare:
|
|
|
|
|
return true;
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2016-11-29 06:11:04 -09:00
|
|
|
bool polly::canSynthesize(const Value *V, const Scop &S, ScalarEvolution *SE,
|
2016-05-23 04:47:09 -08:00
|
|
|
Loop *Scope) {
|
2015-10-09 15:40:24 -08:00
|
|
|
if (!V || !SE->isSCEVable(V->getType()))
|
|
|
|
|
return false;
|
|
|
|
|
|
2017-07-13 04:18:56 -08:00
|
|
|
const InvariantLoadsSetTy &ILS = S.getRequiredInvariantLoads();
|
2016-03-01 12:44:06 -09:00
|
|
|
if (const SCEV *Scev = SE->getSCEVAtScope(const_cast<Value *>(V), Scope))
|
2015-10-09 15:40:24 -08:00
|
|
|
if (!isa<SCEVCouldNotCompute>(Scev))
|
2017-07-13 04:18:56 -08:00
|
|
|
if (!hasScalarDepsInsideRegion(Scev, &S.getRegion(), Scope, false, ILS))
|
2015-10-09 15:40:24 -08:00
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2016-02-06 00:19:40 -09:00
|
|
|
|
2017-07-19 12:41:56 -08:00
|
|
|
llvm::BasicBlock *polly::getUseBlock(const llvm::Use &U) {
|
2016-02-06 00:19:40 -09:00
|
|
|
Instruction *UI = dyn_cast<Instruction>(U.getUser());
|
|
|
|
|
if (!UI)
|
|
|
|
|
return nullptr;
|
|
|
|
|
|
|
|
|
|
if (PHINode *PHI = dyn_cast<PHINode>(UI))
|
|
|
|
|
return PHI->getIncomingBlock(U);
|
|
|
|
|
|
|
|
|
|
return UI->getParent();
|
|
|
|
|
}
|
2016-06-27 17:37:13 -08:00
|
|
|
|
2017-06-29 04:47:41 -08:00
|
|
|
llvm::Loop *polly::getFirstNonBoxedLoopFor(llvm::Loop *L, llvm::LoopInfo &LI,
|
|
|
|
|
const BoxedLoopsSetTy &BoxedLoops) {
|
|
|
|
|
while (BoxedLoops.count(L))
|
|
|
|
|
L = L->getParentLoop();
|
|
|
|
|
return L;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
llvm::Loop *polly::getFirstNonBoxedLoopFor(llvm::BasicBlock *BB,
|
|
|
|
|
llvm::LoopInfo &LI,
|
|
|
|
|
const BoxedLoopsSetTy &BoxedLoops) {
|
|
|
|
|
Loop *L = LI.getLoopFor(BB);
|
|
|
|
|
return getFirstNonBoxedLoopFor(L, LI, BoxedLoops);
|
|
|
|
|
}
|
2018-04-20 10:55:44 -08:00
|
|
|
|
|
|
|
|
bool polly::isDebugCall(Instruction *Inst) {
|
|
|
|
|
auto *CI = dyn_cast<CallInst>(Inst);
|
|
|
|
|
if (!CI)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
Function *CF = CI->getCalledFunction();
|
|
|
|
|
if (!CF)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
return std::find(DebugFunctions.begin(), DebugFunctions.end(),
|
|
|
|
|
CF->getName()) != DebugFunctions.end();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool hasDebugCall(BasicBlock *BB) {
|
|
|
|
|
for (Instruction &Inst : *BB) {
|
|
|
|
|
if (isDebugCall(&Inst))
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool polly::hasDebugCall(ScopStmt *Stmt) {
|
|
|
|
|
// Quick skip if no debug functions have been defined.
|
|
|
|
|
if (DebugFunctions.empty())
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
if (!Stmt)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
for (Instruction *Inst : Stmt->getInstructions())
|
|
|
|
|
if (isDebugCall(Inst))
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
if (Stmt->isRegionStmt()) {
|
|
|
|
|
for (BasicBlock *RBB : Stmt->getRegion()->blocks())
|
|
|
|
|
if (RBB != Stmt->getEntryBlock() && ::hasDebugCall(RBB))
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2021-03-15 09:13:21 -08:00
|
|
|
|
|
|
|
|
/// Find a property in a LoopID.
|
|
|
|
|
static MDNode *findNamedMetadataNode(MDNode *LoopMD, StringRef Name) {
|
|
|
|
|
if (!LoopMD)
|
|
|
|
|
return nullptr;
|
|
|
|
|
for (const MDOperand &X : drop_begin(LoopMD->operands(), 1)) {
|
|
|
|
|
auto *OpNode = dyn_cast<MDNode>(X.get());
|
|
|
|
|
if (!OpNode)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
auto *OpName = dyn_cast<MDString>(OpNode->getOperand(0));
|
|
|
|
|
if (!OpName)
|
|
|
|
|
continue;
|
|
|
|
|
if (OpName->getString() == Name)
|
|
|
|
|
return OpNode;
|
|
|
|
|
}
|
|
|
|
|
return nullptr;
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-02 18:18:46 -09:00
|
|
|
static std::optional<const MDOperand *> findNamedMetadataArg(MDNode *LoopID,
|
|
|
|
|
StringRef Name) {
|
2021-04-24 01:10:55 -08:00
|
|
|
MDNode *MD = findNamedMetadataNode(LoopID, Name);
|
|
|
|
|
if (!MD)
|
2022-12-03 17:50:29 -09:00
|
|
|
return std::nullopt;
|
2021-04-24 01:10:55 -08:00
|
|
|
switch (MD->getNumOperands()) {
|
|
|
|
|
case 1:
|
|
|
|
|
return nullptr;
|
|
|
|
|
case 2:
|
|
|
|
|
return &MD->getOperand(1);
|
|
|
|
|
default:
|
|
|
|
|
llvm_unreachable("loop metadata has 0 or 1 operand");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-02 18:18:46 -09:00
|
|
|
std::optional<Metadata *> polly::findMetadataOperand(MDNode *LoopMD,
|
|
|
|
|
StringRef Name) {
|
2021-03-15 09:13:21 -08:00
|
|
|
MDNode *MD = findNamedMetadataNode(LoopMD, Name);
|
|
|
|
|
if (!MD)
|
2022-12-03 17:50:29 -09:00
|
|
|
return std::nullopt;
|
2021-03-15 09:13:21 -08:00
|
|
|
switch (MD->getNumOperands()) {
|
|
|
|
|
case 1:
|
|
|
|
|
return nullptr;
|
|
|
|
|
case 2:
|
|
|
|
|
return MD->getOperand(1).get();
|
|
|
|
|
default:
|
|
|
|
|
llvm_unreachable("loop metadata must have 0 or 1 operands");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-02 18:18:46 -09:00
|
|
|
static std::optional<bool> getOptionalBoolLoopAttribute(MDNode *LoopID,
|
|
|
|
|
StringRef Name) {
|
2021-04-24 01:10:55 -08:00
|
|
|
MDNode *MD = findNamedMetadataNode(LoopID, Name);
|
|
|
|
|
if (!MD)
|
2022-12-03 17:50:29 -09:00
|
|
|
return std::nullopt;
|
2021-04-24 01:10:55 -08:00
|
|
|
switch (MD->getNumOperands()) {
|
|
|
|
|
case 1:
|
|
|
|
|
return true;
|
|
|
|
|
case 2:
|
|
|
|
|
if (ConstantInt *IntMD =
|
|
|
|
|
mdconst::extract_or_null<ConstantInt>(MD->getOperand(1).get()))
|
|
|
|
|
return IntMD->getZExtValue();
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
llvm_unreachable("unexpected number of options");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool polly::getBooleanLoopAttribute(MDNode *LoopID, StringRef Name) {
|
2022-06-19 09:34:41 -08:00
|
|
|
return getOptionalBoolLoopAttribute(LoopID, Name).value_or(false);
|
2021-04-24 01:10:55 -08:00
|
|
|
}
|
|
|
|
|
|
2023-01-02 18:18:46 -09:00
|
|
|
std::optional<int> polly::getOptionalIntLoopAttribute(MDNode *LoopID,
|
|
|
|
|
StringRef Name) {
|
2021-04-24 01:10:55 -08:00
|
|
|
const MDOperand *AttrMD =
|
2022-06-19 09:34:41 -08:00
|
|
|
findNamedMetadataArg(LoopID, Name).value_or(nullptr);
|
2021-04-24 01:10:55 -08:00
|
|
|
if (!AttrMD)
|
2022-12-03 17:50:29 -09:00
|
|
|
return std::nullopt;
|
2021-04-24 01:10:55 -08:00
|
|
|
|
|
|
|
|
ConstantInt *IntMD = mdconst::extract_or_null<ConstantInt>(AttrMD->get());
|
|
|
|
|
if (!IntMD)
|
2022-12-03 17:50:29 -09:00
|
|
|
return std::nullopt;
|
2021-04-24 01:10:55 -08:00
|
|
|
|
|
|
|
|
return IntMD->getSExtValue();
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-15 09:13:21 -08:00
|
|
|
bool polly::hasDisableAllTransformsHint(Loop *L) {
|
|
|
|
|
return llvm::hasDisableAllTransformsHint(L);
|
|
|
|
|
}
|
|
|
|
|
|
2021-04-24 01:10:55 -08:00
|
|
|
bool polly::hasDisableAllTransformsHint(llvm::MDNode *LoopID) {
|
|
|
|
|
return getBooleanLoopAttribute(LoopID, "llvm.loop.disable_nonforced");
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-15 09:13:21 -08:00
|
|
|
isl::id polly::getIslLoopAttr(isl::ctx Ctx, BandAttr *Attr) {
|
|
|
|
|
assert(Attr && "Must be a valid BandAttr");
|
|
|
|
|
|
|
|
|
|
// The name "Loop" signals that this id contains a pointer to a BandAttr.
|
|
|
|
|
// The ScheduleOptimizer also uses the string "Inter iteration alias-free" in
|
|
|
|
|
// markers, but it's user pointer is an llvm::Value.
|
|
|
|
|
isl::id Result = isl::id::alloc(Ctx, "Loop with Metadata", Attr);
|
|
|
|
|
Result = isl::manage(isl_id_set_free_user(Result.release(), [](void *Ptr) {
|
|
|
|
|
BandAttr *Attr = reinterpret_cast<BandAttr *>(Ptr);
|
|
|
|
|
delete Attr;
|
|
|
|
|
}));
|
|
|
|
|
return Result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
isl::id polly::createIslLoopAttr(isl::ctx Ctx, Loop *L) {
|
|
|
|
|
if (!L)
|
|
|
|
|
return {};
|
|
|
|
|
|
|
|
|
|
// A loop without metadata does not need to be annotated.
|
|
|
|
|
MDNode *LoopID = L->getLoopID();
|
|
|
|
|
if (!LoopID)
|
|
|
|
|
return {};
|
|
|
|
|
|
|
|
|
|
BandAttr *Attr = new BandAttr();
|
|
|
|
|
Attr->OriginalLoop = L;
|
|
|
|
|
Attr->Metadata = L->getLoopID();
|
|
|
|
|
|
|
|
|
|
return getIslLoopAttr(Ctx, Attr);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool polly::isLoopAttr(const isl::id &Id) {
|
|
|
|
|
if (Id.is_null())
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
return Id.get_name() == "Loop with Metadata";
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
BandAttr *polly::getLoopAttr(const isl::id &Id) {
|
|
|
|
|
if (!isLoopAttr(Id))
|
|
|
|
|
return nullptr;
|
|
|
|
|
|
|
|
|
|
return reinterpret_cast<BandAttr *>(Id.get_user());
|
|
|
|
|
}
|