similar to: Is every intrinsic norecurse?

Hi, Also, I think there is a bigger problem lurking than just with norecurse. I think that in general, functionattrs is not very good with attributes when intrinsics are present. E.g. https://bugs.llvm.org/show_bug.cgi?id=34696 Here dbg.value prevents both norecurse and readnone from being deduced. So, it would be nice to fix this for norecurse, but it would be even nicer to fix it for

> From: piotrekpad at gmail.com [mailto:piotrekpad at gmail.com] On Behalf Of Piotr Padlewski > Sent: den 16 oktober 2017 17:33 > > Hi David, > The patch didn't get a lot of attention, so probably others does not > consider it a huge deal. Anyway, if someone is willing to review this, I > can pursue rebasing it. Okay. We are interested in getting something akin to your

Ah I see. I can't think of a way that would help users in any particular way offhand. I hadn't considered exposing it to clang users - do you think there is merit in that? James On Thu, 5 Nov 2015 at 16:08 Aaron Ballman <aaron at aaronballman.com> wrote: > On Thu, Nov 5, 2015 at 11:06 AM, James Molloy <james at jamesmolloy.co.uk> > wrote: > > Hi Aaron, > >

> On 2015-Nov-05, at 08:31, Aaron Ballman <aaron at aaronballman.com> wrote: > > On Thu, Nov 5, 2015 at 11:26 AM, James Molloy <james at jamesmolloy.co.uk> wrote: >> Ah I see. >> >> I can't think of a way that would help users in any particular way offhand. >> I hadn't considered exposing it to clang users - do you think there is merit

Hi Aaron, I think it must necessarily be exposed to users - clang must add it in certain circumstances for example. I don't think this is particularly different to many other attributes such as nocapture/nounwind, that are exposed to users and can be set by users in exceptional circumstances but are primarily inferred by the midend. James On Thu, 5 Nov 2015 at 16:03 Aaron Ballman <aaron

[Adding llvm-dev and re-stating the situation for llvm-dev's benefit] *RFC: A new attribute, "norecurse".* In some cases, it is possible to demote global variables to local variables. This is possible when the global is only used in one function, and that function is known not to recurse (because if the function recurses, a local variable cannot be equivalent to a global as the

Hi, GlobalOpt may not consider demoting globals to locals in the "main" function when C is used. It used to consider "main" specifically prior to commit r253168 , for both C and C++. Since r253168, the check for the norecurse attribute may prevent "main" from being considered. This happens because the Function Attributes pass will not add the norecurse

Hi Mehdi, You are right – modifying the Function Attributes pass to mark “main” as norecurse would break the C standard (unless it has a similar statement regarding “main” that the C++ standard has – I cannot find it), so that’s a no-go. Looks like there was an attempt to bypass library calls in the Function Attributes pass for the purpose of detecting norecurse functions:

I think the conceptual issues have largely been sorted out, it is mostly that it is *much* harder to deduce norecurse than it might seem like superficially. On Mon, Mar 21, 2016 at 4:02 PM Mehdi Amini <mehdi.amini at apple.com> wrote: > On Mar 21, 2016, at 3:57 PM, Sanjin Sijaric via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi, > > GlobalOpt may not

>From cfab42b40752f6dc44971b3c48523b917b374e91 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering at redhat.com> Date: Fri, 4 Sep 2009 18:00:23 +0200 Subject: [PATCH libguestfs] avoid build-from-scratch failure due to missing daemon/configure * bootstrap: Don't use autoreconf's --norecursive option. We require the default --recursive behavior in order to create

The test case that you added in this revision fails on several of the power buildbots (for example, http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/20127) and also when I build it locally: FAIL: Clang :: CodeGenCXX/main-norecurse.cpp (2951 of 27722) ******************** TEST 'Clang :: CodeGenCXX/main-norecurse.cpp' FAILED ******************** Script: --

Hello all, I have a custom allocator, and would like to teach LLVM about its semantics. In particular, I would like LLVM to kill allocations that are "dead", similar to dead new in C++. Consider this example: ; ModuleID = '<stdin>' source_filename = "Module" ; Function Attrs: inaccessiblememonly noinline norecurse nounwind declare i8* @alloc(i64)

Hi, On my phone right now but I'll fish out the pertinent threads when I get to the office. Keyword searches for 'norecurse' on llvm-dev will probably get most of them. Indeed, this correctness improvement caused a performance regression on some programs. There is a way to revert to the old, broken behaviour: '-mllvm -force-attribute=main:norecurse'. Given how many people run

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, I have some IR module from random generation (mostly ineffective instructions). It has a function with void return, and two function arguments where one is a reference. Therefore, I expect every instruction not altering the value at the 2nd arguments address should be ineffective. Here is the function definition (see below for full ll): define void @_Z27entityMainDataInputCallbackdRd(double

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 Devs, going by this link https://llvm.org/docs/LangRef.html#floatenv it says that floating point operation does not have side effects by defaults. but when compile a test case i.e. cat a.c float foo(float a, float b) { return a+b; } $clang a.c -O2 -S -emit-llvm emit ir like: $cat a.ll --------------------------------------- ; ModuleID = 'a.c' source_filename = "a.c" target

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*

Hi: I am trying to implement interval arithmetic through llvm. I have a problem with the rounding mode with llvm.experimental.constrained.cos I have two pieces of codes: ; Function Attrs: norecurse nounwind readnone ssp uwtable define double @cosine_down(double returned) local_unnamed_addr #0 {   ; call the llvm intrinsic to perform downward cosine

looks like experimental/work in progress support: https://reviews.llvm.org/D62731 On Tue, May 26, 2020 at 10:39 PM kamlesh kumar via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Wed, May 27, 2020 at 11:06 AM kamlesh kumar <kamleshbhalui at gmail.com> > wrote: > >> Hi Devs, >> going by this link https://llvm.org/docs/LangRef.html#floatenv >>