similar to: How to remove vector.memcheck when noalias is really safe

Hello, Currently the noalias attribute can be applied on function parameters and return value, or via scoped alias on store. The problem is that there is no easy way to apply the noalias attribute on a pointer that is loaded indirectly (e.g from the field of an aggregate, or from a memory location - though for this you can still use scoped alias, but they are a lot more intrusive) The idea

I'm building a simple R extension around a CUDA-enabled dynamic library, and I want to run the whole package with cuda-memcheck for debugging purposes. I can run it just fine with Valgrind: $ R --no-save -d valgrind < test.R However, if I try the same thing with cuda-memcheck, $ R --no-save -d cuda-memcheck < test.R I get: *** Further command line arguments ('--no-save ')

Thanks for the feedback. Sounds like that at this point in time we can’t really settle on a single strategy. We probably want to support all of these uses-cases: 1. A common early loop-versioning pass, probably fairly conservative initially (e.g. if you need a single memcheck to remove all may-aliasing from a hight-trip-count loop it’s probably a good idea to version). Even if the pass would

Adam, Please find the attached test case (run with ToT opt -O3). As you can see, `y_body` successfully is vectorized, though %33 and %46 are deemed MayAlias despite their exclusive use in loads ands stores marked with `llvm.mem.parallel_loop_access`. Many Thanks, Josh On Thu, Mar 19, 2015 at 12:55 PM, Adam Nemet <anemet at apple.com> wrote: > > > On Mar 19, 2015, at 9:43 AM,

It seems that at some point in the not-so-distant-past that the loop vectorizer gained the ability to vectorize loops without explicit `llvm.loop` & `llvm.mem.parallel_loop_access` metadata. While that's awesome, there seems to be a regression in that `llvm.mem.parallel_loop_access` metadata doesn't make it into the alias analysis, and therefore a `vector.memcheck` basic block is

I mean something like a target-specific fence machine instruction which forces ordering of all loads/stores. I want to clarify the meaning of "noalias" in this case. Is the fence machine instruction considered "touching" all memory and thus breaks the "noalias" contract? Xiaoyi From: Eli Friedman [mailto:eli.friedman at gmail.com] Sent: Wednesday, June 12, 2013 8:08

Hi, I am trying to understand what is or what should be the correct semantic of the function parameter attribute noalias. I found: http://zion.cs.uiuc.edu/bugs/show_bug.cgi?id=1373 and http://www.llvm.org/docs/LangRef.html#paramattrs from the first link: "The semantics of 'noalias' are that they "define a new object". Any pointer derived from it ("it" being

It’s a good thought in general Adam, but I worried about following scenarios: 1) As Dibyendu already mentioned Check1 + Check2 is not very clear. If your intent is superset/union of check1 & check2 then I’m not sure it will always help passes those needs smaller checks (i.e. loop distribution) Every pass has a different need of runtime check, i.e. vectorizer checks each memory against all

I have ran under valgrind memcheck the process using libLLVM-2.9.so (rev.126022) and got several errors: ==24227== Invalid read of size 1 ==24227== at 0x40274C9: memcpy (mc_replace_strmem.c:497) ==24227== by 0x40D5B84: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in

Thanks Nick! Can you just check sanity before I commit? (Or suggest a better name for the function...) -----Original Message----- From: Nick Lewycky [mailto:nicholas at mxc.ca] Sent: Sunday, May 26, 2013 09:54 To: Kuperstein, Michael M Cc: LLVMdev at cs.uiuc.edu Subject: Re: [LLVMdev] Mixing noalias and regular arguments Kuperstein, Michael M wrote: > Ping? Pong! Sorry for the slow review,

Hi, I have the following test case: define void @foo(<2 x float>* noalias nocapture %out, <2 x float>* noalias nocapture %data0) nounwind { entry: %val1 = load <2 x float>* %data0, align 8 store <2 x float> %val1, <2 x float>* %out, align 8 fence acq_rel %val2 = load <2 x float>* %data0, align 8 store <2 x float> %val2, <2 x float>*

Hi, Looking at how noalias is defined: https://llvm.org/docs/LangRef.html#noalias-and-alias-scope-metadata "When evaluating an aliasing query, **if for some domain**, the set of scopes with that domain in one instruction’s alias.scope list is a subset of (or equal to) the set of scopes for that domain in another instruction’s noalias list, then the two memory accesses are assumed not to

So fence only forces ordering of atomic instructions. Let me change my question then. If I have a target-specific intrinsic which forces ordering of ordinary load/store instructions. Then should it also force ordering of load/stores to noalias pointers in caller functions? Thanks, Xiaoyi From: Eli Friedman [mailto:eli.friedman at gmail.com] Sent: Wednesday, June 12, 2013 7:06 PM To: Guo,

On Sun, Nov 14, 2010 at 2:37 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > On Sun, Nov 14, 2010 at 11:45 AM, Reid Kleckner <reid.kleckner at gmail.com> wrote: >> On Sun, Nov 14, 2010 at 11:17 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: >>> To fix that and compile C++ correctly while aggressively >>> devirtualizing it, we would need

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

----- Original Message ----- > From: "Raul Silvera" <rsilvera at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chandler Carruth" <chandlerc at google.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, November 14, 2014 10:34:39 AM > Subject: Re: [LLVMdev] Upcoming

Right now, I don't see any way to declare that a pointer value within a function does not alias any pointer not based on it. Basically, I would like to be able to apply "noalias" to an instruction/virtual reg the same way that noalias is applied to function arguments. A few weeks ago when discussing devirtualization possibilities in C++, it turned out that while you can assume that

Regarding the name, I'm not sure noaliasAtFunctionEntry makes sense, for two reasons: a) The pointer involved may not be defined at entry. b) We already have something which is similar in spirit - IsIdentifiedObject. That covers the 3 cases I have in the new function, but also two additional ones: GlobalValues which are not GlobalAliases, and byval arguments. Unfortunately, a check of

On Thu, Jun 13, 2013 at 11:39 AM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote: > In a multi-threaded environment, in order to ensure the memory ordering > expressed by the memory fence, certain memory operations should not be > moved across the fence, right?**** > > ** > Yes, but operations on noalias pointers don't fall into that category. For noalias pointers, while

----- Original Message ----- > From: "Alex Bradbury" <asb at asbradbury.org> > To: llvm-dev at lists.llvm.org > Cc: "Hal Finkel" <hfinkel at anl.gov> > Sent: Sunday, November 8, 2015 10:30:09 AM > Subject: Re: noalias parameter attribute not currently exploited by alias analysis? > > On 2 November 2015 at 20:20, Alex Bradbury <asb at