search for: memloc

...all? MemoryDependenceAnalysis::getDependency uses MemoryDependenceAnalysis::getPointerDependencyFrom, which does the following analysis at the end: // See if this instruction (e.g. a call or vaarg) mod/ref's the pointer. AliasAnalysis::ModRefResult MR = AA->getModRefInfo(Inst, MemLoc); // If necessary, perform additional analysis. if (MR == AliasAnalysis::ModRef) MR = AA->callCapturesBefore(Inst, MemLoc, DT); switch (MR) { case AliasAnalysis::NoModRef: // If the call has no effect on the queried pointer, just ignore it. continue;...

Hi, This came up in https://reviews.llvm.org/D38569, and I'd like some input on what's the best way to get alias and mod-ref info without having two alias calls. A couple of ideas: (a) Extend the getModRefInfo interface (+getModRefBehavior, +gerArgModRefInfo) to return a pair {ModRefInfo, AliasResult}. The AliasResult can be optional based on an argument e.g.: struct MRI_AR {

...with tons of loads and stores to test against each other. > That's actually fairly rare in bootstrap, as you can see. > Let me get you some test cases. > SG, thanks! > > My guess is that we should go with mustmod. > > > As for callsites, adding mustmod works for call, memloc and call, call > testing. > > > > On Mon, Oct 9, 2017, 4:48 PM Alina Sbirlea <alina.sbirlea at gmail.com> > wrote: > >> Hi, >> >> This came up in https://reviews.llvm.org/D38569, and I'd like some input >> on what's the best way to get al...

...ith tons of loads and stores to test against > each other. That's actually fairly rare in bootstrap, as you can see. > Let me get you some test cases. > > My guess is that we should go with mustmod. I agree. -Hal > > > As for callsites, adding mustmod works for call, memloc and call, call > testing. > > > On Mon, Oct 9, 2017, 4:48 PM Alina Sbirlea <alina.sbirlea at gmail.com > <mailto:alina.sbirlea at gmail.com>> wrote: > > Hi, > > This came up in https://reviews.llvm.org/D38569, and I'd like some > input on...

...500 / 48.228 / 48.453 > > Larger case hits it 1872 times. Timings, average over 5 runs (s): > 100 / 23.575 / 23.962 > 200 / 23.874 / 23.848 > > > My guess is that we should go with mustmod. >>> >>> >>> As for callsites, adding mustmod works for call, memloc and call, call >>> testing. >>> >> >>> >> >>> >>> On Mon, Oct 9, 2017, 4:48 PM Alina Sbirlea <alina.sbirlea at gmail.com> >>> wrote: >>> >>>> Hi, >>>> >>>> This came up in https://re...

...ision 148708) +++ lib/Analysis/MemoryDependenceAnalysis.cpp (working copy) @@ -323,6 +323,14 @@ !TD.fitsInLegalInteger(NewLoadByteSize*8)) return 0; + if (LI->getParent()->getParent()->hasFnAttr(Attribute::AddressSafety) && + LIOffs+NewLoadByteSize > MemLocEnd) { + // We will be reading past the location accessed by the original program. + // While this is safe in a regular build, Address Safety analysys tools + // may start reporting false warnings. So, do't do widening. + return 0; + } + // If a load of this width wou...

________________________________ From: Kostya Serebryany [kcc at google.com] Sent: Wednesday, December 28, 2011 2:46 PM To: Criswell, John T Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] load widening conflicts with AddressSanitizer On Wed, Dec 28, 2011 at 12:40 PM, Criswell, John T <criswell at illinois.edu<mailto:criswell at illinois.edu>> wrote: Dear All, I think adding

Chris Lattner wrote: > On Thu, 2 Dec 2004, Brent Monroe wrote: > >>I'm trying to add the xadd instruction to the X86 back end. >>xadd r/m32, r32 >>exchanges r/m32 and r32, and loads the sum into r/m32. I'm >>interested in the case where the destination operand is a >>memory location. >> >>I've added the following entry to

...Timings, average over 5 runs (s): >>> 100 / 23.575 / 23.962 >>> 200 / 23.874 / 23.848 >>> >>> >>> My guess is that we should go with mustmod. >>>>> >>>>> >>>>> As for callsites, adding mustmod works for call, memloc and call, call >>>>> testing. >>>>> >>>> >>>>> >>>> >>>>> >>>>> On Mon, Oct 9, 2017, 4:48 PM Alina Sbirlea <alina.sbirlea at gmail.com> >>>>> wrote: >>>>> >>&...

...; libLTO.dylib`llvm::AliasAnalysis::getModRefInfo(this=0x000000010eba5c30, > S=0x000000010a1a22e0, Loc=0x00007fff5fbf6268) + 120 at AliasAnalysis.cpp:288 > frame #3: 0x0000000103a0a814 > libLTO.dylib`llvm::MemoryDependenceAnalysis::getPointerDependencyFrom(this=0x000000010e6cf0c0, > MemLoc=0x00007fff5fbf6268, isLoad=true, ScanIt=llvm::BasicBlock::iterator at > 0x00007fff5fbf4390, BB=0x000000010a19ffa0, QueryInst=0x000000010a1a20c8) + > 1908 at MemoryDependenceAnalysis.cpp:570 > frame #4: 0x0000000103a0ffa5 > libLTO.dylib`llvm::MemoryDependenceAnalysis::GetNonLocalInfo...

...ysis/MemoryDependenceAnalysis.cpp (working copy) > @@ -323,6 +323,14 @@ > !TD.fitsInLegalInteger(NewLoadByteSize*8)) > return 0; > + if (LI->getParent()->getParent()->hasFnAttr(Attribute::AddressSafety) && > + LIOffs+NewLoadByteSize > MemLocEnd) { > + // We will be reading past the location accessed by the original program. > + // While this is safe in a regular build, Address Safety analysys tools > + // may start reporting false warnings. So, do't do widening. > + return 0; > + } > + >...

On Fri, Jul 17, 2015 at 9:13 AM Evgeny Astigeevich < evgeny.astigeevich at arm.com> wrote: > It’s Dhrystone. > Dhrystone has historically not been a good indicator of real-world performance fluctuations, especially at this small of a shift. I'd like to see if we see any fluctuation on larger and more realistic application benchmarks. One advantage of the flag being set is that we