search for: norecursive

Hi folks, I've been measuring some devirtualization statistics and I found that when barriers are introduced, the number of functions marked as norecurse is lower. The llvm.group.barrier is obviously norecursive and I've been thinking: is every intrinsic norecurse? I think it make sense to mark all of the intrinsics that can be considered as norecursive this way, so it won't gonna stop the optimizer marking functions as norecurse. Best Piotr -------------- next part -------------- An HTML attachm...

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

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

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:

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

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: --

> 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

> 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

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

[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

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, > >

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

Hi, opt -O1 converts the attached test.ll to test_opt.ll. " opt --version LLVM (http://llvm.org/): LLVM version 3.8.0 DEBUG build with assertions. Built Jun 23 2016 (18:32:09). Default target: i686-pc-linux-gnu Host CPU: k8-sse3 " test.ll: " ; ModuleID = 'test.bc' @__mla__system.1 = global i32 0 @0 = internal global [12 x i8] zeroinitializer @1 = internal global

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

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

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*

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