[PATCH] D34188: Don't check side effects for functions outside of SCoP
Singapuram Sanjay Srivallabh via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Jun 14 08:42:30 PDT 2017
singam-sanjay added inline comments.
================
Comment at: lib/Support/SCEVValidator.cpp:121
bool polly::isConstCall(llvm::CallInst *Call) {
if (Call->mayReadOrWriteMemory())
return false;
----------------
grosser wrote:
> singam-sanjay wrote:
> > For polyhedral analysis, do we also need the function to evaluate to the same value always (not just side effect free) inside the Scop ? I got this notion from the name of the function.
> >
> > If that's the case, is it possible to check for that ? ( I have a feeling that it's not feasible )
> Yes, that's what we need. I believe that we can assume that if a function does not read memory it will always return the same value.
>
> However, there is another bug that slipped in. I assumed mayReadOrWriteMemory corresponds to is-always-executed. This is not the case, so we should likely limit this to functions that are called in the entry block (or at least post-dominate the entry block).
> Yes, that's what we need. I believe that we can assume that if a function does not read memory it will always return the same value.
What about random number generators ?
> However, there is another bug that slipped in. I assumed mayReadOrWriteMemory corresponds to is-always-executed. This is not the case, so we should likely limit this to functions that are called in the entry block (or at least post-dominate the entry block).
How does mayReadOrWrite become mustReadOrWrite for those functions ?
================
Comment at: lib/Support/SCEVValidator.cpp:125
for (auto &Operand : Call->arg_operands())
if (!isa<ConstantInt>(&Operand))
return false;
----------------
grosser wrote:
> singam-sanjay wrote:
> > Can we consider `llvm::ConstantFP` as well ? Or any constant type ?
> We use this for ScalarEvolution expressions, which are all integral. So I am note really seeing if/when we would need other constant types. In general, I made good experience with working use-case driven. Meaning, in case we have a benchmark/code that could benefit from such constructs, we add them.
> We use this for ScalarEvolution expressions, which are all integral.
I had this doubt in the context of detecting **any** ConstCall to a function, including something like `sqrt(2.3) `.
Thanks for the info ! it was very helpful.
> Meaning, in case we have a benchmark/code that could benefit from such constructs, we add them.
Makes sense.
================
Comment at: lib/Support/SCEVValidator.cpp:396
ValidatorResult visitUnknown(const SCEVUnknown *Expr) {
Value *V = Expr->getValue();
----------------
grosser wrote:
> singam-sanjay wrote:
> > How is this function called ? I don't find any explicit call to this function and the code [[ http://llvm.org/reports/coverage/tools/polly/lib/Support/SCEVValidator.cpp.gcov.html | coverage reports ]] are a month old.
> I wrote an email to @sylvestre.ledru (see llvm-dev) to check about the status of the coverage reports.
>
> It is called by the SCEVVisitor which serves as base class for the SCEVValidator.
> I wrote an email to @sylvestre.ledru (see llvm-dev) to check about the status of the coverage reports.
I thought the coverage reports were automated, like CI services, which start compiling as soon as a commit is made.
> It is called by the SCEVVisitor which serves as base class for the SCEVValidator.
Oh ok.
Repository:
rL LLVM
https://reviews.llvm.org/D34188
More information about the llvm-commits
mailing list