search for: functioncomparator

...l, you don't actually need a <=> operator to use a > sort. A > > strict ordering ( < operator) is sufficient. (Note that for > mergefunc, a > > strict weak ordering is not sufficient, it must be a total ordering.) > That could be done with int FunctionComparator::compare(). We can > replace it with bool FunctionComparator::less(). Though for all > other cmp methods need at least 2 bits of information as result: > 1. Whether things are equal. > 2. Whether left less than right. > > As for FunctionComparator::compare(), c...

...return 0; > +} > > At a high level, you don't actually need a <=> operator to use a sort. A > strict ordering ( < operator) is sufficient. (Note that for mergefunc, a > strict weak ordering is not sufficient, it must be a total ordering.) That could be done with int FunctionComparator::compare(). We can replace it with bool FunctionComparator::less(). Though for all other cmp methods need at least 2 bits of information as result: 1. Whether things are equal. 2. Whether left less than right. As for FunctionComparator::compare(), conversion into less() will increase time of sa...

...ndly format (like text, markdown or rst) is probably better. - Have you profiled this? What's the speedup? I second Raul's question about whether improving the hashing (or doing secondary hashing) could result in a larger benefit (maybe even with simpler code). - At the beginning of FunctionComparator::cmpEnumerate, you have a comment that you can't introduce an order relation for cross-references, and the following code: // Unfortunately we can't introduce order relation for // cross reference case. It is possible for self-reference only. if (V1 == F1) {...

...he comparison result was unknown, returning “false” would conservatively consider the functions distinct, so we had no correctness issues. However, with your patch, *everything* must be accurately compared, right? Are there any cases where you can’t accurately order functions? (Is FunctionComparator::cmpEnumerate an example?) If these are problems, maybe you can use the previous ==-style comparison to confirm. > Raul, > > Yes. you right it is O(N*log(N)). And yes, I have some ideas about hashing. > Though in the end of hashing improvement I still see the tree. I'll exp...

Hi all, I propose simple improvement for MergeFunctions pass, that reduced its complexity from O(N^2) to O(log(N)), where N is number of functions in module. The idea, is to replace the result of comparison from "bool" to "-1,0,1". In another words: define order relation on functions set. To be sure, that functions could be comparable that way, we have to prove that order

Hi all, Previous patch has been split onto series of small changes. On each stage (after each patch) MergeFunctions pass is compilable and stable. Please find patches in attachment for review. To apply all patches at once, use "apply-patches.sh" script as follows: 0. Place "apply-patches.sh" in same directory with patches. 1. cd <llvm-sources-dir> 2. "bash

Am Mi., 29. Mai 2019 um 13:31 Uhr schrieb Shawn Landden via llvm-dev <llvm-dev at lists.llvm.org>: > > On Wed, May 29, 2019 at 10:49 AM David Jones via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > Under certain circumstances, my compiler outputs basic blocks having the same function: > > > > bb_97: ;

..._back(Swap.getValue(0)); Results.push_back(Swap.getValue(1)); diff --git a/lib/Transforms/IPO/MergeFunctions.cpp b/lib/Transforms/IPO/MergeFunctions.cpp index 0ab1c76..a3c3f0f 100644 --- a/lib/Transforms/IPO/MergeFunctions.cpp +++ b/lib/Transforms/IPO/MergeFunctions.cpp @@ -341,7 +341,10 @@ bool FunctionComparator::isEquivalentOperation(const Instruction *I1, FI->getSynchScope() == cast<FenceInst>(I2)->getSynchScope(); if (const AtomicCmpXchgInst *CXI = dyn_cast<AtomicCmpXchgInst>(I1)) return CXI->isVolatile() == cast<AtomicCmpXchgInst>(I2)->isVolatile() &amp...