similar to: [RFC] A nofree (and nosynch) function attribute: Mixing dereferenceable and delete

[+Richard] On 07/11/2018 08:29 AM, Sanjoy Das wrote: > I'm not sure if nosynch is sufficient. What if we had: > > void f(int& x) { > if (false) { > int r0 = x; > } > } > > // other thread > free(<pointer to x>); > > The source program is race free, but LLVM may speculate the read from > x (seeing that it is dereferenceable) creating a

Thanks, Richard. Based on the feedback from this thread, I'll move forward with the patches for nofree, nosync, adding a new corresponding dereferenceable attribute (my suggestion is to name this dereferenceable_on_entry; suggestions welcome), and updating Clang is emit this new attribute instead of the current one.  -Hal On 07/11/2018 06:43 PM, Richard Smith wrote: > On Wed, 11 Jul 2018

Right now, we have Value::getPointerDereferenceableBytes() and Value::getPointerAlignment() that allow to query these properties for a value. However, neither does any "reasoning" that would require looking at other values, e.g., they do pure local lookups. To do actual reasoning we have the "isDereferenceableAndAlignedPointer()"-family of functions in Loads.h. Additionally,

Hi all, Let's see an example (from Alexandre Isoard) first: **************************************************************************************** ; RUN: opt -ipsccp -deadargelim -licm -O2 -S < %s @g = internal global i32 0 ; Function Attrs: argmemonly define internal void @foo(i32* nonnull dereferenceable(4) %arg, i32 %val) #0 { entry: store i32 %val, i32* %arg ret void } define

Thank you Hal and Stefan! Bug report is filed: https://bugs.llvm.org/show_bug.cgi?id=46717 And Stefan, I think 'attributor' is a really nice pass, and can infer more precise and useful attributes, which may give more opportunities for optimization. But we shouldn't depend on 'attributor' to correct wrong function attributes, because we cannot run 'attributor' after

Hey list, I've recently done the first test run of bumping our Burst compiler from LLVM 10 -> 11 now that the branch has been cut, and have noticed an apparent loop vectorization codegen regression for X86 with AVX or AVX2 enabled. The following IR example is vectorized to 4 wide with LLVM 11 and trunk whereas in LLVM 10 it (correctly as per what we want) vectorized it 8 wide matching the

Tried a bunch of them there (x86-64, haswell, znver2) and they all defaulted to 4-wide - haswell additionally caused some extra loop unrolling but still with 8-wide pows. Cheers, -Neil. On Thu, Jul 16, 2020 at 2:39 PM Roman Lebedev <lebedev.ri at gmail.com> wrote: > Did you specify the target CPU the code should be optimized for? > For clang that is -march=native/znver2/... /

> Since the scope is “opaque” and target specific, can you elaborate what kind of generic optimization can be performed? Some optimizations that are related to a single thread could be done without needing to know the actual memory scope. For example, an atomic acquire can restrict reordering memory operations after it, but allow reordering of memory operations (except another atomic acquire)

On 7/14/20 4:34 PM, Hal Finkel via llvm-dev wrote: > > On 7/14/20 11:28 AM, Fangqing Du wrote: >> Thank you Hal and Stefan! >> >> Bug report is filed: https://bugs.llvm.org/show_bug.cgi?id=46717 >> <https://bugs.llvm.org/show_bug.cgi?id=46717> >> >> And Stefan, >> I think 'attributor' is a really nice pass, and can infer more >>

So for us we use SLEEF to actually implement the libcalls (LLVM intrinsics) that LLVM by default would generate - and since SLEEF has highly optimal 8-wide pow, optimized for AVX and AVX2, we really want to use that. So we would not see 4/8 libcalls and instead see 1 call to something that lights up the ymm registers. I guess the problem then is that the default expectation is that pow would be

On 12/01/2014 02:42 PM, Andrew Trick wrote: > >> On Dec 1, 2014, at 2:21 PM, Philip Reames <listmail at philipreames.com >> <mailto:listmail at philipreames.com>> wrote: >> >> >> On 12/01/2014 11:14 AM, Andrew Trick wrote: >>> >>>> On Oct 21, 2014, at 4:03 PM, Philip Reames >>>> <listmail at philipreames.com

The LRM (http://llvm.org/docs/LangRef.html#llvm-lifetime-start-intrinsic) essentially states that: - ptr is dead before a call to "lifetime.start size, ptr" - ptr is dead after a call to "lifetime.end size, ptr" This is all good and fine, and the expected use case is that all "lifetime.end size, ptr" markers are matched with a preceding "lifetime.start

Two thoughts: 1. I think that we should aim for regularity, to the extent possible, and so we should treat nonnull, align, etc. similarly w.r.t. to whether they produce poison or UB. 2. I was thinking about the following last night, and it clarified for me why having an not_poison attribute makes sense and seems useful, and how poison/UB might affect things on a function-call boundary itself.

On 12/01/2014 11:14 AM, Andrew Trick wrote: > >> On Oct 21, 2014, at 4:03 PM, Philip Reames <listmail at philipreames.com >> <mailto:listmail at philipreames.com>> wrote: >> >> Sanjoy made a good point. We don't actually need a new variant of >> "invariant.start". Simply using an invariant.start with no uses >> gives us a notion

Hi all, I've included an RFC for a heap profiler design I've been working on in conjunction with David Li. Please send any questions or feedback. For sanitizer folks, one area of feedback is on refactoring some of the *ASAN shadow setup code (see the Shadow Memory section). Thanks, Teresa RFC: Sanitizer-based Heap Profiler Summary This document provides an overview of an LLVM

> > This seems fine to me. The optimizer can (soundly) conclude that %p is > dead after the "lifetime.end" (for the two instructions), and dead before > the "lifetime.start" (for the *single* instruction in that basic block, > *not* for the previous BB). This seems like the proper result for this > example, am I missing something? > What if I put that in

Problem LLVM's memory model for NonAtomic accesses is generally fairly weak, but explicitly disallows inserting stores that didn't occur in the original program.  This is required for any potentially shared location, but is overkill for any memory location which is provably only accessed by a single thread. My particular motivating example is a single thread private field in our

On 5 November 2014 11:51, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Reid Kleckner" <rnk at google.com> > > To: "Philip Reames" <listmail at philipreames.com> > > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > > Sent: Wednesday, November 5, 2014 12:54:30 PM >

Here are some comments. It seems to me there are 2 (mostly separate) aspects: 1. Teaching clang how to do domination / post-domination analysis, so that the lifetime information (alloca/dealloca, or lifetime markers) can be set in the right locations in the IR. Such an analysis should be able to understand the language scopes, as well as labels / gotos and EH. The results of this analysis

Hi, I am observing a strange behaviour in which Clang ignores __restirct when I include some standard headers. For example, this code: void vec_add(int* __restrict a, int* __restrict b, int n) { #pragma unroll 4 for(int i=0; i<n; ++i) { a[i] += b[i]; } } results in: ; Function Attrs: nofree norecurse nounwind define dso_local void @_Z7vec_addPiS_i(i32*