search for: all_of

...t; > Then a CFG such as this: > A > / \ > B C > | / \ > | D E > | | / > | | / > | |/ > | / > |/ > F > > - Assume calls are in B and ANY_OF(C,D,E): CSR allocation is cheap > everywhere > > - Assume calls are in C or ALL_OF(D,E): CSR allocation is cheap in > ALL_OF(C,D,E); CSR allocation is expensive in ALL_OF(A,B,F) > > - Assume only call is in ANY_OF(B,D,E): CSR allocation is cheap only > in that block, expensive everywhere else > > I think this construction would give us what we want, but there...

...gt; B C >>> | / \ >>> | D E >>> | | / >>> | | / >>> | |/ >>> | / >>> |/ >>> F >>> - Assume calls are in B and ANY_OF(C,D,E): CSR allocation is cheap >>> everywhere >>> - Assume calls are in C or ALL_OF(D,E): CSR allocation is cheap in >>> ALL_OF(C,D,E); CSR allocation is expensive in ALL_OF(A,B,F) >>> - Assume only call is in ANY_OF(B,D,E): CSR allocation is cheap >>> only >>> in that block, expensive everywhere else >>> I think this construction would...

On 2017-10-30 21:20, Hal Finkel wrote: > On 10/30/2017 12:20 PM, junbuml at codeaurora.org wrote: >> On 2017-10-27 19:50, Hal Finkel wrote: >>> On 10/27/2017 03:32 PM, Jun Lim via llvm-dev wrote: >>> >>>> When compiling C code below for AArach64, I saw that shrink-wrapping >>>> didn't happen due to the very early uses of CSRs in the entry

...such as this: >> A >> / \ >> B C >> | / \ >> | D E >> | | / >> | | / >> | |/ >> | / >> |/ >> F >> - Assume calls are in B and ANY_OF(C,D,E): CSR allocation is cheap >> everywhere >> - Assume calls are in C or ALL_OF(D,E): CSR allocation is cheap in >> ALL_OF(C,D,E); CSR allocation is expensive in ALL_OF(A,B,F) >> - Assume only call is in ANY_OF(B,D,E): CSR allocation is cheap >> only >> in that block, expensive everywhere else >> I think this construction would give us what we wan...

The simplest way to run a clang test case that I know of is to clone both llvm and clang repos, run all the tests, then run an individual test. IIRC like so: git clone llvm ...... cd llvm/tools git clone clang ..... cd ../../ mkdir build cd build cmake ../llvm ninja check-clang ./bin/llvm-lit -v ./tools/clang/test/Sema/asm.c On Sun, May 6, 2018 at 7:10 AM, Sedat Dilek via llvm-dev <

Hi, while experimenting with llvmlinux on Debian/testing AMD64 I wanted to run some x86-64 ASM tests. I fell over [1] and wanted to run it. So, I cloned clang from Git... $ git clone https://github.com/llvm-mirror/clang.git I looked through some docs where I have seen I need "llvm-lit" or "lit.py". The Debian package llvm-7-tools from <apt.llvm.org> does ship

...m/include/llvm/ADT/DenseMap.h:17, from /home/sdi/src/llvm/llvm/lib/CodeGen/MIRParser/MIParser.h:17, from /home/sdi/src/llvm/llvm/lib/CodeGen/MIRParser/MIParser.cpp:14: /home/sdi/src/llvm/llvm/include/llvm/ADT/STLExtras.h:908:6: warning: mangled name for ‘bool llvm::all_of(R&&, UnaryPredicate) [with R = llvm::StringRef&; UnaryPredicate = int (*)(int) throw ()]’ will change in C++17 because the exception specification is part of a function type [-Wnoexcept-type] bool all_of(R &&Range, UnaryPredicate P) { ^~~~~~ [1440/2954] Building CXX objec...

...er matchers, or some way to define optional parameters? I''m trying to match something like: .find( 42 ) || .find( 42, {:conditions=>nil,:includes=>nil} ) Or for that matter, 42 followed by nothing or anything... Halp? I''ve tried different nested combos with any_of/all_of/anything, but getting lost trying. --Andrew Vit

...actly the same as its store size and the store // size is a legal integer type. if (!Ty->isIntegerTy() && Ty->isSized() && DL.isLegalInteger(DL.getTypeStoreSizeInBits(Ty)) && DL.getTypeStoreSizeInBits(Ty) == DL.getTypeSizeInBits(Ty)) { if (std::all_of(LI.user_begin(), LI.user_end(), [&LI](User *U) { auto *SI = dyn_cast<StoreInst>(U); return SI && SI->getPointerOperand() != &LI; })) { ... After ignoring load/stores which satisfy something like the above code, you can always fallback to...

So this change did indeed have an effect! :) I’m seeing regressions in a number of benchmarks mainly due to a host of extra bitcasts that get introduced. Here’s the problem I’m seeing in a nutshell: 1) There is a Phi with input type double 2) Polly demotes the phi into a load/store of type double 3) InstCombine canonicalizes the load/store to use i64 instead of double 4)

Buen día estimados, Tengo el siguiente código: df_1 <- data.frame(ana = c(15, 20, 30), maria = c(15,20,30), jose = c(15, 20, 30)) df_2 <- data.frame(nombre = c("jose", "ana", "maria"), valor = c(1,2,3)) # Find the corresponding columns in df_1 based on the values in df_2$nombre cols <- match(df_2$nombre, names(df_1)) # Subtract the values of df_2$valor

...he C++0X standard is introducing several new generic free functions in several existing headers: <iterator> next prev begin end <utility> move forward <memory> addressof undeclare_reachable <functional> ref cref bind <algorithm> all_of any_of none_of move copy_if <numeric> iota (this is not a complete list). Additionally when /any/ two libraries are mixed (e.g. llvm and boost), there is a large potential for name clashes even when namespaces are judiciously used. The carefully crafted C++ library should b...

Sorry, always end up not replying to the list: The main issue with dealing with next this way is that people adding new uses of next will probably not be using c++0x and therefore won't know it's ambiguous and that it needs to be qualified. There are also two issues with rvalue references and the STL: 1. EquivalenceClasses, in the insert and findLeader functions, it uses map functions

On 2014 Mar 4, at 20:23, Chandler Carruth <chandlerc at google.com> wrote: > On Tue, Mar 4, 2014 at 8:07 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > There’s a decent selection of range adaptors in Boost.Range [1]. I’m not sure the license [2] allows copying the source (IANAL), but any reason not use the same names? I don’t see any reason to reinvent the

On Dec 16, 2018, at 11:44 AM, Stephen Kelly via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 25/11/2018 14:43, Stephen Kelly via llvm-dev wrote: >> However this is a proposal for more modern thinking regarding the permissiveness of auto in LLVM codebases. >> Currently the rule on the use of auto is here: > > Hi, > > Thanks for the input on this topic,