search for: getpointers

Hey Ben, This change broke some clangd code (no failing test, mea culpa), because it changed the move semantics. Previously: a moved-from llvm::Optional was None (for all types). Now: a moved-from llvm::Optional is None (for non-trivial types), and has the old value (for trivial types). FWIW, a moved-from std::optional is *not* nullopt, and contains the moved-from value. This seems sad to me,

That's an unintentional change. However, the reason for this change was to make optional of trivially copyable types trivially copyable, adding a user-provided move ctor would break that again :( I'm leaning towards making the non-trivial version of llvm::Optional more like std::optional. In the long term std::optional is going to replace llvm::Optional. How bad would that be for your use

On Wed, Jan 24, 2018 at 11:47 PM, Benjamin Kramer <benny.kra at gmail.com> wrote: > That's an unintentional change. However, the reason for this change > was to make optional of trivially copyable types trivially copyable, > adding a user-provided move ctor would break that again :( > > I'm leaning towards making the non-trivial version of llvm::Optional > more

On 11/12/2011 12:11 AM, Hal Finkel wrote: > On Fri, 2011-11-11 at 23:55 +0100, Tobias Grosser wrote: >> On 11/11/2011 11:36 PM, Hal Finkel wrote: >>> On Thu, 2011-11-10 at 23:07 +0100, Tobias Grosser wrote: >>>> On 11/08/2011 11:29 PM, Hal Finkel wrote: Talking about this I >>>> looked again into ScalarEvolution. >>>> >>>> To

On Fri, 2011-11-11 at 23:55 +0100, Tobias Grosser wrote: > On 11/11/2011 11:36 PM, Hal Finkel wrote: > > On Thu, 2011-11-10 at 23:07 +0100, Tobias Grosser wrote: > >> On 11/08/2011 11:29 PM, Hal Finkel wrote: > >> Talking about this I looked again into ScalarEvolution. > >> > >> To analyze a load, you would do: > >> > >> LoadInst *Load

Hi Rafael, We will try out your patch and check to see how it will fit. You also talked about "It might be even possible to drop the requirement for the size to be known: Replace the call to AtEndOfStream by just trying to read more and checking if it failed, but that is a bit more than I wanted to do for this." That is to remove some calls to getSize()? Is there any expectation that

On Thu, 2011-11-10 at 23:07 +0100, Tobias Grosser wrote: > On 11/08/2011 11:29 PM, Hal Finkel wrote: > > On Tue, 2011-11-08 at 20:24 +0100, Tobias Grosser wrote: > >> On 11/08/2011 03:36 PM, Hal Finkel wrote: > >>> On Tue, 2011-11-08 at 12:12 +0100, Tobias Grosser wrote: > >>>> On 11/08/2011 11:45 AM, Hal Finkel wrote: > > [A lot of performance

On 11/11/2011 11:36 PM, Hal Finkel wrote: > On Thu, 2011-11-10 at 23:07 +0100, Tobias Grosser wrote: >> On 11/08/2011 11:29 PM, Hal Finkel wrote: >> Talking about this I looked again into ScalarEvolution. >> >> To analyze a load, you would do: >> >> LoadInst *Load = ... >> Value *Pointer = Load->getPointer(); >> const SCEV *PointerSCEV =

Hi Rafael, Would you mind waiting for Derek to come back from vacation to discuss this? We do use this code and could improve how it's used and tested within LLVM. Derek is the best person to discuss this, he'll be back in mid-January. Thanks, JF On Fri, Dec 19, 2014 at 6:41 AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > > I CC'ed llvmdev to put a

Full stack trace: opt: /home/xbolva00/LLVM/llvm/include/llvm/ADT/Optional.h:176: T* llvm::Optional<T>::getPointer() [with T = llvm::MemoryLocation]: Assertion `Storage.hasVal' failed. Stack dump: 0. Program arguments: opt aaa.ll -dse -S 1. Running pass 'Function Pass Manager' on module 'aaa.ll'. 2. Running pass 'Dead Store Elimination' on function

Tobias, I've attached the latest version of my autovectorization patch. I was able to add support for using the ScalarEvolution analysis for load/store pairing (thanks for your help!). This led to a modest performance increase and a modest compile-time increase. This version also has a cutoff as you suggested (although the default value is set high (4000 instructions between pairs) because

On 11/08/2011 11:29 PM, Hal Finkel wrote: > On Tue, 2011-11-08 at 20:24 +0100, Tobias Grosser wrote: >> On 11/08/2011 03:36 PM, Hal Finkel wrote: >>> On Tue, 2011-11-08 at 12:12 +0100, Tobias Grosser wrote: >>>> On 11/08/2011 11:45 AM, Hal Finkel wrote: [A lot of performance results skipped] OK. As expected part of the speedup is because of unrolling, however it

Looks like there are many overloads for "get". http://llvm.org/doxygen/MemoryLocation_8cpp_source.html But nothing for CallInst. Any suggestions how to do a proper one? I will look at it too. 2018-05-22 23:34 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>: > Full stack trace: > > opt: /home/xbolva00/LLVM/llvm/include/llvm/ADT/Optional.h:176: T* >

It works with MemoryLocation MemoryLocation::get(const CallInst *CI) { AAMDNodes AATags; CI->getAAMetadata(AATags); const auto &DL = CI->getModule()->getDataLayout(); return MemoryLocation(CI, DL.getTypeStoreSize(CI->getType()), AATags); } Is it fine? :) 2018-05-22 23:56 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>: > Looks like there are many overloads

You might want to look more carefully at how you're constructing the MemoryLocation.   The first argument is a pointer, and the second argument is the number of bytes pointed to by that pointer (or MemoryLocation::UnknownSize if the number of bytes accessed isn't known). More generally, copy-pasting code you don't understand isn't a good idea. -Eli On 5/22/2018 4:02 PM, Dávid

* if (isStringFromCalloc(Dst, TLI)) should be if (!isStringFromCalloc(Dst, TLI)) but still asserting... 2018-05-22 23:06 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>: > Can you help a bit? > > I try to work with DSE but I got the following assert: > opt: /home/xbolva00/LLVM/llvm/include/llvm/ADT/Optional.h:176: T* > llvm::Optional<T>::getPointer() [with T

IR: define i32 @calloc_strlen_write_between() { %call = tail call noalias i8* @calloc(i32 10, i32 1) store i8 97, i8* %call, align 1 %call1 = tail call i32 @strlen(i8* %call) ret i32 %call1 } static bool eliminateStrlen(CallInst *CI, BasicBlock::iterator &BBI, AliasAnalysis *AA, MemoryDependenceResults *MD, const DataLayout &DL, const TargetLibraryInfo *TLI,

Yeah, sorry for that. Better "It compiles ok (but maybe incorrect code)", not "It works" as I wrote. 2018-05-23 1:08 GMT+02:00 Friedman, Eli <efriedma at codeaurora.org>: > You might want to look more carefully at how you're constructing the > MemoryLocation. The first argument is a pointer, and the second argument > is the number of bytes pointed to by

It looks like the memoryIsNotModifiedBetween assumes the second argument is a store, or some other instruction supported by MemoryLocation::get.  If you're passing in something else, you'll have to compute the MemoryLocation some other way. (Generally, if you're asking a question about an assertion, please include the whole stack trace; it's hard to guess what's happening

Hi, I'm trying to build llvm (git monorepo) on Ubuntu 18.04 with EXPENSIVE_CHECKS enabled and running into various errors compiling SourceMgr.cpp, depending on which host compiler I use. For example with GCC: $ CC=gcc-8 CXX=g++-8 cmake -GNinja -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON ~/git/llvm-project/llvm/ && ninja ... [89/2690] Building CXX object