-
Notifications
You must be signed in to change notification settings - Fork 15.3k
[DA] Add initial support for monotonicity check #162280
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 3 commits
9bfa9d5
d088dbe
9c29421
da8859c
83ab4c6
0d83581
bb17ccd
b708d71
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -128,6 +128,18 @@ static cl::opt<bool> RunSIVRoutinesOnly( | |
| "The purpose is mainly to exclude the influence of those routines " | ||
| "in regression tests for SIV routines.")); | ||
|
|
||
| // TODO: This flag is disabled by default because it is still under development. | ||
| // Enable it or delete this flag when the feature is ready. | ||
| static cl::opt<bool> EnableMonotonicityCheck( | ||
| "da-enable-monotonicity-check", cl::init(false), cl::Hidden, | ||
| cl::desc("Check if the subscripts are monotonic. If it's not, dependence " | ||
| "is reported as unknown.")); | ||
|
|
||
| static cl::opt<bool> DumpMonotonicityReport( | ||
| "da-dump-monotonicity-report", cl::init(false), cl::Hidden, | ||
| cl::desc( | ||
| "When printing analysis, dump the results of monotonicity checks.")); | ||
|
|
||
| //===----------------------------------------------------------------------===// | ||
| // basics | ||
|
|
||
|
|
@@ -177,13 +189,189 @@ void DependenceAnalysisWrapperPass::getAnalysisUsage(AnalysisUsage &AU) const { | |
| AU.addRequiredTransitive<LoopInfoWrapperPass>(); | ||
| } | ||
|
|
||
| namespace { | ||
|
|
||
| /// The type of monotonicity of a SCEV. This property is defined with respect to | ||
| /// the outermost loop that DA is analyzing. | ||
| /// | ||
| /// This is designed to classify the behavior of AddRec expressions, and does | ||
| /// not care about other SCEVs. For example, given the two loop-invariant values | ||
| /// `A` and `B`, `A + B` is treated as Invariant even if the addition wraps. | ||
| enum class SCEVMonotonicityType { | ||
| /// The expression is neither loop-invariant nor monotonic (or we fail to | ||
| /// prove it). | ||
| Unknown, | ||
|
|
||
| /// The expression is loop-invariant with respect to the outermost loop. | ||
| Invariant, | ||
|
|
||
| /// The expression is a (nested) affine AddRec and is monotonically increasing | ||
| /// or decreasing in a signed sense with respect to each loop. Monotonicity is | ||
| /// checked independently for each loop, and the expression is classified as | ||
| /// MultiSignedMonotonic if all AddRecs are nsw. For example, in the following | ||
|
||
| /// loop: | ||
| /// | ||
| /// for (i = 0; i < 100; i++) | ||
| /// for (j = 0; j < 100; j++) | ||
| /// A[i + j] = ...; | ||
| /// | ||
| /// The SCEV for `i + j` is classified as MultiSignedMonotonic. On the other | ||
| /// hand, in the following loop: | ||
| /// | ||
| /// for (i = 0; i < 100; i++) | ||
| /// for (j = 0; j <= (1ULL << 63); j++) | ||
| /// A[i + j] = ...; | ||
| /// | ||
| /// The SCEV for `i + j` is NOT classified as MultiMonotonic, because the | ||
| /// AddRec for `j` wraps in a signed sense. We don't consider the "direction" | ||
| /// of each AddRec. For example, in the following loop: | ||
| /// | ||
| /// for (int i = 0; i < 100; i++) | ||
| /// for (int j = 0; j < 100; j++) | ||
| /// A[i - j] = ...; | ||
| /// | ||
| /// The SCEV for `i - j` is classified as MultiSignedMonotonic, even though it | ||
| /// contains both increasing and decreasing AddRecs. | ||
| /// | ||
| /// Note that we don't check if the step recurrence can be zero. For | ||
| /// example,an AddRec `{0,+,%a}<nsw> is classifed as Monotonic if `%a` can be | ||
| /// zero. That is, the expression can be Invariant. | ||
| MultiSignedMonotonic, | ||
|
||
| }; | ||
|
|
||
| struct SCEVMonotonicity { | ||
| SCEVMonotonicity(SCEVMonotonicityType Type, | ||
| const SCEV *FailurePoint = nullptr); | ||
|
|
||
| SCEVMonotonicityType getType() const { return Type; } | ||
|
|
||
| const SCEV *getFailurePoint() const { return FailurePoint; } | ||
|
|
||
| bool isUnknown() const { return Type == SCEVMonotonicityType::Unknown; } | ||
|
|
||
| void print(raw_ostream &OS, unsigned Depth) const; | ||
|
|
||
| private: | ||
| SCEVMonotonicityType Type; | ||
|
|
||
| /// The subexpression that caused Unknown. Mainly for debugging purpose. | ||
| const SCEV *FailurePoint; | ||
| }; | ||
|
|
||
| struct SCEVMonotonicityChecker | ||
| : public SCEVVisitor<SCEVMonotonicityChecker, SCEVMonotonicity> { | ||
|
Comment on lines
+268
to
+269
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As for the testability, maybe is it better to split the file, like ScalarEvolutionDivision.cpp? Or would it be better to avoid creating separate files unnecessarily? |
||
|
|
||
| SCEVMonotonicityChecker(ScalarEvolution *SE) : SE(SE) {} | ||
|
|
||
| /// Check the monotonicity of \p Expr. \p Expr must be integer type. If \p | ||
| /// OutermostLoop is not null, \p Expr must be defined in \p OutermostLoop or | ||
| /// one of its nested loops. | ||
| SCEVMonotonicity checkMonotonicity(const SCEV *Expr, | ||
| const Loop *OutermostLoop); | ||
|
|
||
| private: | ||
| ScalarEvolution *SE; | ||
|
|
||
| /// The outermost loop that DA is analyzing. | ||
| const Loop *OutermostLoop; | ||
|
|
||
| /// A helper to classify \p Expr as either Invariant or Unknown. | ||
| SCEVMonotonicity invariantOrUnknown(const SCEV *Expr); | ||
|
|
||
| /// Return true if \p Expr is loop-invariant with respect to the outermost | ||
| /// loop. | ||
| bool isLoopInvariant(const SCEV *Expr) const; | ||
|
|
||
| /// A helper to create an Unknown SCEVMonotonicity. | ||
| SCEVMonotonicity createUnknown(const SCEV *FailurePoint) { | ||
| return SCEVMonotonicity(SCEVMonotonicityType::Unknown, FailurePoint); | ||
| } | ||
|
|
||
| SCEVMonotonicity visitAddRecExpr(const SCEVAddRecExpr *Expr); | ||
|
|
||
| SCEVMonotonicity visitConstant(const SCEVConstant *) { | ||
| return SCEVMonotonicity(SCEVMonotonicityType::Invariant); | ||
| } | ||
| SCEVMonotonicity visitVScale(const SCEVVScale *) { | ||
| return SCEVMonotonicity(SCEVMonotonicityType::Invariant); | ||
| } | ||
|
|
||
| // TODO: Handle more cases. | ||
| SCEVMonotonicity visitZeroExtendExpr(const SCEVZeroExtendExpr *Expr) { | ||
| return invariantOrUnknown(Expr); | ||
| } | ||
| SCEVMonotonicity visitSignExtendExpr(const SCEVSignExtendExpr *Expr) { | ||
| return invariantOrUnknown(Expr); | ||
| } | ||
| SCEVMonotonicity visitAddExpr(const SCEVAddExpr *Expr) { | ||
| return invariantOrUnknown(Expr); | ||
| } | ||
| SCEVMonotonicity visitMulExpr(const SCEVMulExpr *Expr) { | ||
| return invariantOrUnknown(Expr); | ||
| } | ||
| SCEVMonotonicity visitPtrToIntExpr(const SCEVPtrToIntExpr *Expr) { | ||
| return invariantOrUnknown(Expr); | ||
| } | ||
| SCEVMonotonicity visitTruncateExpr(const SCEVTruncateExpr *Expr) { | ||
| return invariantOrUnknown(Expr); | ||
| } | ||
| SCEVMonotonicity visitUDivExpr(const SCEVUDivExpr *Expr) { | ||
| return invariantOrUnknown(Expr); | ||
| } | ||
| SCEVMonotonicity visitSMaxExpr(const SCEVSMaxExpr *Expr) { | ||
| return invariantOrUnknown(Expr); | ||
| } | ||
| SCEVMonotonicity visitUMaxExpr(const SCEVUMaxExpr *Expr) { | ||
| return invariantOrUnknown(Expr); | ||
| } | ||
| SCEVMonotonicity visitSMinExpr(const SCEVSMinExpr *Expr) { | ||
| return invariantOrUnknown(Expr); | ||
| } | ||
| SCEVMonotonicity visitUMinExpr(const SCEVUMinExpr *Expr) { | ||
| return invariantOrUnknown(Expr); | ||
| } | ||
| SCEVMonotonicity visitSequentialUMinExpr(const SCEVSequentialUMinExpr *Expr) { | ||
| return invariantOrUnknown(Expr); | ||
| } | ||
| SCEVMonotonicity visitUnknown(const SCEVUnknown *Expr) { | ||
| return invariantOrUnknown(Expr); | ||
| } | ||
| SCEVMonotonicity visitCouldNotCompute(const SCEVCouldNotCompute *Expr) { | ||
| return invariantOrUnknown(Expr); | ||
| } | ||
|
|
||
| friend struct SCEVVisitor<SCEVMonotonicityChecker, SCEVMonotonicity>; | ||
| }; | ||
|
|
||
| } // anonymous namespace | ||
|
|
||
| // Used to test the dependence analyzer. | ||
| // Looks through the function, noting instructions that may access memory. | ||
| // Calls depends() on every possible pair and prints out the result. | ||
| // Ignores all other instructions. | ||
| static void dumpExampleDependence(raw_ostream &OS, DependenceInfo *DA, | ||
| ScalarEvolution &SE, bool NormalizeResults) { | ||
| ScalarEvolution &SE, LoopInfo &LI, | ||
| bool NormalizeResults) { | ||
| auto *F = DA->getFunction(); | ||
|
|
||
| if (DumpMonotonicityReport) { | ||
| SCEVMonotonicityChecker Checker(&SE); | ||
| OS << "Monotonicity check:\n"; | ||
| for (Instruction &Inst : instructions(F)) { | ||
| if (!isa<LoadInst>(Inst) && !isa<StoreInst>(Inst)) | ||
| continue; | ||
| Value *Ptr = getLoadStorePointerOperand(&Inst); | ||
| const Loop *L = LI.getLoopFor(Inst.getParent()); | ||
| const SCEV *PtrSCEV = SE.getSCEVAtScope(Ptr, L); | ||
| const SCEV *AccessFn = SE.removePointerBase(PtrSCEV); | ||
| SCEVMonotonicity Mon = Checker.checkMonotonicity(AccessFn, L); | ||
| OS.indent(2) << "Inst: " << Inst << "\n"; | ||
| OS.indent(4) << "Expr: " << *AccessFn << "\n"; | ||
| Mon.print(OS, 4); | ||
| } | ||
| OS << "\n"; | ||
| } | ||
|
|
||
| for (inst_iterator SrcI = inst_begin(F), SrcE = inst_end(F); SrcI != SrcE; | ||
| ++SrcI) { | ||
| if (SrcI->mayReadOrWriteMemory()) { | ||
|
|
@@ -235,7 +423,8 @@ static void dumpExampleDependence(raw_ostream &OS, DependenceInfo *DA, | |
| void DependenceAnalysisWrapperPass::print(raw_ostream &OS, | ||
| const Module *) const { | ||
| dumpExampleDependence( | ||
| OS, info.get(), getAnalysis<ScalarEvolutionWrapperPass>().getSE(), false); | ||
| OS, info.get(), getAnalysis<ScalarEvolutionWrapperPass>().getSE(), | ||
| getAnalysis<LoopInfoWrapperPass>().getLoopInfo(), false); | ||
| } | ||
|
|
||
| PreservedAnalyses | ||
|
|
@@ -244,7 +433,7 @@ DependenceAnalysisPrinterPass::run(Function &F, FunctionAnalysisManager &FAM) { | |
| << "':\n"; | ||
| dumpExampleDependence(OS, &FAM.getResult<DependenceAnalysis>(F), | ||
| FAM.getResult<ScalarEvolutionAnalysis>(F), | ||
| NormalizeResults); | ||
| FAM.getResult<LoopAnalysis>(F), NormalizeResults); | ||
| return PreservedAnalyses::all(); | ||
| } | ||
|
|
||
|
|
@@ -670,6 +859,70 @@ bool DependenceInfo::intersectConstraints(Constraint *X, const Constraint *Y) { | |
| return false; | ||
| } | ||
|
|
||
| //===----------------------------------------------------------------------===// | ||
| // SCEVMonotonicity | ||
|
|
||
| SCEVMonotonicity::SCEVMonotonicity(SCEVMonotonicityType Type, | ||
| const SCEV *FailurePoint) | ||
| : Type(Type), FailurePoint(FailurePoint) { | ||
| assert( | ||
| ((Type == SCEVMonotonicityType::Unknown) == (FailurePoint != nullptr)) && | ||
| "FailurePoint must be provided iff Type is Unknown"); | ||
| } | ||
|
|
||
| void SCEVMonotonicity::print(raw_ostream &OS, unsigned Depth) const { | ||
| OS.indent(Depth) << "Monotonicity: "; | ||
| switch (Type) { | ||
| case SCEVMonotonicityType::Unknown: | ||
| assert(FailurePoint && "FailurePoint must be provided for Unknown"); | ||
| OS << "Unknown\n"; | ||
| OS.indent(Depth) << "Reason: " << *FailurePoint << "\n"; | ||
| break; | ||
| case SCEVMonotonicityType::Invariant: | ||
| OS << "Invariant\n"; | ||
| break; | ||
| case SCEVMonotonicityType::MultiSignedMonotonic: | ||
| OS << "MultiSignedMonotonic\n"; | ||
| break; | ||
| } | ||
| } | ||
|
|
||
| bool SCEVMonotonicityChecker::isLoopInvariant(const SCEV *Expr) const { | ||
| return !OutermostLoop || SE->isLoopInvariant(Expr, OutermostLoop); | ||
| } | ||
|
|
||
| SCEVMonotonicity SCEVMonotonicityChecker::invariantOrUnknown(const SCEV *Expr) { | ||
| if (isLoopInvariant(Expr)) | ||
| return SCEVMonotonicity(SCEVMonotonicityType::Invariant); | ||
| return createUnknown(Expr); | ||
| } | ||
|
|
||
| SCEVMonotonicity | ||
| SCEVMonotonicityChecker::checkMonotonicity(const SCEV *Expr, | ||
| const Loop *OutermostLoop) { | ||
| assert(Expr->getType()->isIntegerTy() && "Expr must be integer type"); | ||
| this->OutermostLoop = OutermostLoop; | ||
| return visit(Expr); | ||
| } | ||
|
|
||
| SCEVMonotonicity | ||
| SCEVMonotonicityChecker::visitAddRecExpr(const SCEVAddRecExpr *Expr) { | ||
| if (!Expr->isAffine() || !Expr->hasNoSignedWrap()) | ||
| return createUnknown(Expr); | ||
|
|
||
| const SCEV *Start = Expr->getStart(); | ||
| const SCEV *Step = Expr->getStepRecurrence(*SE); | ||
|
|
||
| SCEVMonotonicity StartMon = visit(Start); | ||
| if (StartMon.isUnknown()) | ||
| return StartMon; | ||
|
|
||
| if (!isLoopInvariant(Step)) | ||
| return createUnknown(Expr); | ||
|
|
||
| return SCEVMonotonicity(SCEVMonotonicityType::MultiSignedMonotonic); | ||
| } | ||
|
|
||
| //===----------------------------------------------------------------------===// | ||
| // DependenceInfo methods | ||
|
|
||
|
|
@@ -3479,10 +3732,19 @@ bool DependenceInfo::tryDelinearize(Instruction *Src, Instruction *Dst, | |
| // resize Pair to contain as many pairs of subscripts as the delinearization | ||
| // has found, and then initialize the pairs following the delinearization. | ||
| Pair.resize(Size); | ||
| SCEVMonotonicityChecker MonChecker(SE); | ||
| const Loop *OutermostLoop = SrcLoop ? SrcLoop->getOutermostLoop() : nullptr; | ||
| for (int I = 0; I < Size; ++I) { | ||
| Pair[I].Src = SrcSubscripts[I]; | ||
| Pair[I].Dst = DstSubscripts[I]; | ||
| unifySubscriptType(&Pair[I]); | ||
|
|
||
| if (EnableMonotonicityCheck) { | ||
| if (MonChecker.checkMonotonicity(Pair[I].Src, OutermostLoop).isUnknown()) | ||
| return false; | ||
| if (MonChecker.checkMonotonicity(Pair[I].Dst, OutermostLoop).isUnknown()) | ||
| return false; | ||
| } | ||
|
Comment on lines
+3769
to
+3774
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Another question here, otherwise LGTM. If we have mutliple subscripts and all of them are monotonic, how could the other monotonicity check (line 4083-4) fail? We need to answer this to make sure we are not running the test redundantly.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Consider the following case (godbolt): ; char A[][32];
; for (i = 0; i < 1ll << 62; i++)
; for (j = 0; j < 32; j++)
; if (i < (1ll << 57))
; A[i][j] = 0;
define void @outer_loop_may_wrap(ptr %a) {
entry:
br label %loop.i.header
loop.i.header:
%i = phi i64 [ 0, %entry ], [ %i.inc, %loop.i.latch ]
br label %loop.j.header
loop.j.header:
%j = phi i64 [ 0, %loop.i.header ], [ %j.inc, %loop.j.latch ]
%cond = icmp slt i64 %i, 144115188075855872 ; 2^57
br i1 %cond, label %if.then, label %loop.j.latch
if.then:
%gep = getelementptr inbounds [32 x i8], ptr %a, i64 %i, i64 %j
store i8 0, ptr %gep
br label %loop.j.latch
loop.j.latch:
%j.inc = add nuw nsw i64 %j, 1
%ec.j = icmp eq i64 %j.inc, 32
br i1 %ec.j, label %loop.i.latch, label %loop.j.header
loop.i.latch:
%i.inc = add nuw nsw i64 %i, 1
%ec.i = icmp eq i64 %i.inc, 4611686018427387904 ; 2^62
br i1 %ec.i, label %exit, label %loop.i.header
exit:
ret void
}The subscripts
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Added the above test case. |
||
| } | ||
|
|
||
| return true; | ||
|
|
@@ -3815,6 +4077,14 @@ DependenceInfo::depends(Instruction *Src, Instruction *Dst, | |
| Pair[0].Src = SrcEv; | ||
| Pair[0].Dst = DstEv; | ||
|
|
||
| SCEVMonotonicityChecker MonChecker(SE); | ||
| const Loop *OutermostLoop = SrcLoop ? SrcLoop->getOutermostLoop() : nullptr; | ||
| if (EnableMonotonicityCheck) | ||
| if (MonChecker.checkMonotonicity(Pair[0].Src, OutermostLoop).isUnknown() || | ||
| MonChecker.checkMonotonicity(Pair[0].Dst, OutermostLoop).isUnknown()) | ||
|
Comment on lines
+4109
to
+4111
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have a basic question about these two tests here: If we have an AddRec with a nsw flag, that means this AddRec doesn't wrap. Why that is not enough and we need to recursively check each component of AddRec? I guess the flags from SCEV assume all the internal components are fixed and only the top level calculation doesn't overflow? Is that correct? In that case you may want to have a testcase where the top level AddRec has nsw, but monotonicity fails. I didn't see that in your test, but in other test files we have examples of that. It is helpful to add that.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. However the example that I see is this loop (the first test in SameSDLoops.ll) It is strange that we cannot prove monotonicity here:
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
In my understanding, your guess is correct. I added a test case
I don't know much about how nowrap flags are transferred from IR to SCEV, but this appears to be a limitation of SCEV. At a glance, it’s not obvious that the second store Anyway, for this specific case, I think we could perform additional cheap analysis similar to range analysis in SCEV, since all values except the induction variables are constants. That said, I'm not planning to include such a feature in this PR. |
||
| return std::make_unique<Dependence>(Src, Dst, | ||
| SCEVUnionPredicate(Assume, *SE)); | ||
|
|
||
| if (Delinearize) { | ||
| if (tryDelinearize(Src, Dst, Pair)) { | ||
| LLVM_DEBUG(dbgs() << " delinearized\n"); | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using
Monotonicis fine if the documentation/definition reflects what it is meant to be, even if it only implements it for AddRec atm. That would give a clear path how it cold to be extended.Could be understood as FlagNSW of the outermost loop only, but I think you mean wrapping of any nested loop.
The current doxygen for
SCEVMonotonicityTypesays it it only for AddRecs, and mixes monotonicity and wrapping (I think we consider monotonicity to imply no-wrapping, so if a wrapping AddRec is found it cannot be monotonic, but the other way around may not be true, e.g. with a non-affine SCEVAddRecExpr). Only caring about AddRecs seems arbitrary. Why? What is the property we want to ensure? Could you use a clearer definition?I think this is easier to explain with monotonicity, which is always relative to a variates, the loop induction variables in this case.$f_{A,B}(i)$ , where $i$ is the variate.
AandBare just constants (soA + Balso evaluates to just a constant, even if it is the result of an overflow, and could have been hoisted out of the loop), i.e. the function over which we defined monotonicity isThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it's clearly mixing up the definition and the implementation. The definition itself doesn't need to be limited to AddRecs. I'll rewrite the definition.
Correct, that's what I tried to describe.
Do you mean that monotonicity is not defined for constants in the first place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Revised the definition of monotonicity. I believe it's better than before...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Constants, in the sense of a parametric function, are not the subject of the monotonicity property, only the function argument/variate is. It is the question "when modifying x, how does$f_c(x)$ behave". The answer may depend on $c$ , such as $f_c(x)=c*x$ (strictly monotonically decreasing for $c < 0$ , monotonic for $c > 0$ , strictly monotonically increasing for $c > 0$ ). Like in case of a derivative, we ask for the slope of $f_c(x)$ at some position $x$ . The answer may depend on $f'_c(x)=c$ ), but we are not asking for the slope of infinitismally close $c$ and $c'$ .
c(For loop nests,$c$ is typically the increament of a loop/stride of an array subscript and therefore usually a literal constant, i.e. known $c$ . If $c$ is not known at compile-time, the query of monotonicity must either include "for which value of $c$ , possibly $f_c(x)=c*x$ example above, without any wrapping behavior, the answer can be monotonic, as long as we do not care whether it is strict/increasing/decreasing.
c?", or answer with the most pessimistic result for anyUnkown, i.e. using a forall quantifier. For theFor DA, it just means within the scope of the anlysis,$c$ will always have the same value, the behavior of the same LLVM function called with a different value of $c'$ when is irrelvant. DA does not give you dependency information accross function calls (respectively: different values of an invariant variable), only between loop iterations within the same function call. If
aandbare invariant/constant,a + bis just some value, no matter how it was computed. It could also be an unknown functiong(a,b), as long as we know that the result ofgonly depends on its arguments.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I think I got it. It seems that I was mixed parameters and arguments for a parametric function.