similar to: Should ValueTracking::GetUnderlyingObject stop on Alloca instructions rather than calling SimplifyInstruction?

Yep. Makes sense to me. There's nothing to simplify or constant-fold about an alloca. -Hal On 04/12/2017 04:23 PM, Craig Topper wrote: > Ping > > ~Craig > > On Fri, Apr 7, 2017 at 1:25 PM, Craig Topper <craig.topper at gmail.com > <mailto:craig.topper at gmail.com>> wrote: > > I notice that GetUnderlyingObject has a few checks, but alloca >

Hi Matthew, > I'm investigating a problem with "Machine Instruction Scheduling" that is rooted > in incorrect alias information. > > Things go wrong in the "Merge disjoint stack slots"[1] pass when a store > instruction fails to get updated after its stack slot is merged. As a result, > when "Machine Instruction Scheduling" runs, it incorrectly

Hello all. I'm investigating a problem with "Machine Instruction Scheduling" that is rooted in incorrect alias information. Things go wrong in the "Merge disjoint stack slots"[1] pass when a store instruction fails to get updated after its stack slot is merged. As a result, when "Machine Instruction Scheduling" runs, it incorrectly re-orders the store and a

After discussing with Nick Lewycky in the IRC channel, here comes a less aggressive patch. We were worried that a constant pointer could alias with a GlobalValue. Also, if one pointer could be a GlobalValue and the other a GlobalAlias with the GlobalValue as aliasee. However, I was not able to produce a test where this happens wihout the getUnderlyingObject() returning the same value. It

Hans Wennborg wrote: > After discussing with Nick Lewycky in the IRC channel, here comes a less > aggressive patch. > > We were worried that a constant pointer could alias with a GlobalValue. > Also, if one pointer could be a GlobalValue and the other a GlobalAlias > with the GlobalValue as aliasee. > However, I was not able to produce a test where this happens wihout the

For those not following along, startingin r301379, Simplify* in InstructionSimplify now can just take a query struct instead of 8000 optional arguments. Nothing is really new since it used the same thing under the covers. I'm slowly converting the old uses away (deletion of the old APIs is a different question). Staring at most of them, i could just directly convert them using braced list

LLVM has two similar bits of infrastructure: a simplifyInstructionsInBlock function and a SimplifyInstructions pass, both intended to be lightweight “fix up this code without doing serious optimizations” functions, as far as I can tell. I don’t think either is used in a performance-sensitive place in-tree; the former is mostly called in minor places when doing CFG twiddling, and the latter seems

Dan Gohman wrote: > On Nov 4, 2009, at 6:43 AM, Hans Wennborg wrote: > >> Here is another change I'd like to suggest to the BasicAliasAnalysis. >> >> LLVM fails to remove the dead store in the following code: >> >> %t = type { i32 } >> >> define void @f(%t* noalias nocapture %stuff ) { >> %p = getelementptr inbounds %t* %stuff, i32 0,

On Nov 4, 2009, at 6:43 AM, Hans Wennborg wrote: > Here is another change I'd like to suggest to the BasicAliasAnalysis. > > LLVM fails to remove the dead store in the following code: > > %t = type { i32 } > > define void @f(%t* noalias nocapture %stuff ) { > %p = getelementptr inbounds %t* %stuff, i32 0, i32 0 > > store i32 1, i32* %p; <-- This

Trying to apply patches.. What's your base revision? Joe On Nov 15, 2012, at 5:44 PM, Michael Ilseman <milseman at apple.com> wrote: > New patches with review feedback incorporated: > * Changed single letter flags to short abbreviations ('S' ==> 'nsz') > * Indentation fixes > * Comments don't state function names > >

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 = llvm::MemoryLocation]: Assertion `Storage.hasVal' failed. static bool eliminateStrlen(CallInst *CI, BasicBlock::iterator &BBI, AliasAnalysis *AA, MemoryDependenceResults

New patches with review feedback incorporated: * Changed single letter flags to short abbreviations ('S' ==> 'nsz') * Indentation fixes * Comments don't state function names -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fast-math-flags-added-to-FPMathOperator.patch Type: application/octet-stream Size: 4937 bytes Desc: not

* 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

----- Original Message ----- > From: "Chris Lattner" <clattner at apple.com> > To: "Chandler Carruth" <chandlerc at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov>, "Justin Bogner" > <mail at justinbogner.com>, "Duncan Exon Smith"

On Mon, Jul 13, 2015 at 10:21 PM Chris Lattner <clattner at apple.com> wrote: > > > On Jul 13, 2015, at 8:19 PM, Chandler Carruth <chandlerc at gmail.com> > wrote: > > > > Ok folks, > > > > I wrote up the general high-level thoughts I have about stateful AA in a > separate thread. But we need to sort out the completely and horribly broken >

memoryIsNotModifiedBetween is precisely the sort of expensive walk we shouldn't be doing... I'm surprised it hasn't caused any serious issues yet.  Ideally, what we should be doing is using MemorySSA to find a dependency from the memset: if the closest dependency is the malloc, there aren't any stores between the memset and the malloc.  (But we aren't using MemorySSA in

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

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,

Hi all, One of the reasons the Livermore Loops couldn't be vectorized is that it was using global structures to hold the arrays. Today, I'm investigating why is that so and how to fix it. My investigation brought me to LoopVectorizationLegality::canVectorizeMemory(): if (WriteObjects.count(*it)) { DEBUG(dbgs() << "LV: Found a possible read/write reorder:"

Though semantically equivalent in this case, however I think you should use logical ors here not bitwise. + bool any() { + return UnsafeAlgebra | NoNaNs | NoInfs | NoSignedZeros | + AllowReciprocal; + } Gripe: This pattern is probably super fast and has precedence… but the code is non-obvious: SubclassOptionalData = (SubclassOptionalData & ~BitToSet) | (B * BitToSet); This is