similar to: [RFC] `opt-out` attribute list for intrinsics

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/... /

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

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

Hi Karl, Roman, On 01/28, Roman Lebedev via llvm-dev wrote: > On Tue, Jan 28, 2020 at 8:09 PM Karl Rehm via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I was looking into how the global optimization pass fares against > > things like what's reported in > > https://bugs.llvm.org/show_bug.cgi?id=44676 I need to take a closer look but I would have expected

[+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

On 01/28, Karl Rehm wrote: > > > > I need to take a closer look but I would have expected BasicAA to be > > able to determine that `do_log` and `R` cannot alias. In the -Os version > > (lower right here https://gcc.godbolt.org/z/KLaeiH), the write to `R` > > clobbers the read from `do_log` which prevents us from removing the > > load/store pair. My reasoning

For a datapoint, Julia uses the following function description to implement approximately the capability of those functions. We then also verify that there's no direct inttoptr/ptrtoint into our gc-tracked AddressSpace with a custom verifier pass (among other sanity checks). I can provide additional details and pointers to our gc-root tracking algorithm implementation if desired (I also plan

It's not about the pointer per se but the object it points to. If we have 2 objects of which we know the minimal/maximal size respectively we can sometimes conclude the objects must be different. Accesses to different objects do not alias. We already use that logic but we don't have the upper bound size as an attribute. Hence, it only applies if we know the exact size, basically is we see

Hey everyone, I was looking into how the global optimization pass fares against things like what's reported in https://bugs.llvm.org/show_bug.cgi?id=44676 Looking at this, I think it would be pretty trivial to optimize that down given that there are already threading assumptions made: https://godbolt.org/z/u6ZqoB Is this something I can look into? Another thing is that currently *all* external

On Sun, 28 Jun 2020 at 13:01, Stefan Stipanovic <stefomeister at gmail.com> wrote: > Is the channel now purposefully invite-only? If so, how is one supposed to join? It's not. More people were added as moderators to curb the problem instead. Are you having trouble joining the channel?

Hi, everyone, I'd like to propose adding a nofree function attribute to indicate that a function does not, directly or indirectly, call a memory-deallocation function (e.g., free, C++'s operator delete). Clang/LLVM can currently misoptimize functions that:  1. Have a reference argument.  2. Free the memory backing the object to which the reference is bound during the function's

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

Hi Fahad, > > Improve dynamic memory related capabilities of Attributor. For example > Improve HeapToStackConversions. Maybe such deductions can help safety > (dis)provers. For example, can we improve the use-after-free bug detection > using some attributes? > Stefan should know more about H2S. Regarding the use-after-free, I don't > think there's currently any plans

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

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*

At 8/16/2020 10:39 AM, Stefan Stipanovic wrote: >Hi Paul, > >I've read "LLVM Code-Review Policies and Practices," but I remain unsure of a couple of things. Do I always wait for an actual "LGTM", or can people approve the patch for submission in other ways? > >The patch is accepted through Phabricator with or without a message (the message is usually LGTM or

On 9/7/20 10:56 AM, Nicolai Hähnle wrote: > Hi Johannes and Atmn, > > On Sat, Sep 5, 2020 at 7:07 AM Johannes Doerfert via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >>  > In any case, please explain the intended behavior of the attribute and >>  > the metadata upon inlining. >> >> The attribute will be attached to the caller upon

Hi everyone, Last year I found about GSoC and llvm bit to late to apply. I noticed that "Improve function attribute inference" project idea was not taken. Does anyone know if someone has worked on it in the meantime? If not, is someone interested in mentoring? Nuno Lopes or someone else? Thanks and regards, Stefan. -------------- next part -------------- An HTML attachment was

Hi Farad, > I tried to do this for the NoUnwind attribute Hmm, I don't have experience with this attribute but it seems like a good starting point since it doesn't do much. First of all, be sure that you run with: opt -passes=attributor -attributor-disable=false This uses the new pass manager which is another discussion. Now, to the point: If you open nounwind.ll, it has a bunch of