similar to: [PATCH] D14227: Add a new attribute: norecurse

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

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 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, 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 James, One last thing - is your target upstream? or are you working on a downstream target? Cheers, James On Tue, 8 Sep 2020 at 23:02, Nagurne, James <j-nagurne at ti.com> wrote: > I greatly appreciate you going back to gather that intel, James. It > actually helps my understanding of the whole pipeliner puzzle quite a bit! > > > > I did identify, like you, that the

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

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

> 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

Hi James, Having not worked on this for circa one year I've gone and refreshed my memory. We have a pretty capable implementation of swing modulo scheduling downstream, distinct from the MachinePipeliner implementation. Historically, MachinePipeliner had very tight coupling between the finding of a suitable schedule and emitting the code that adheres to that schedule. I spent quite a bit of

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

Yes, the full test case is: static int x = 100; int y = whatever; int main() { x = -101; y = whatever that's not whatever above; printf("%d\n", y); printf("%d\n", x); return 0; } You are correct, in the above test case the globalopt does not make the transformation.... however, I think the original issue still stands, it really shouldn't be doing it

Hi James, Adding Hendrik, who has taken over ownership of the downstream code involved. I can also add background about the rationale, of that helps? It was added to ignore induction variable update code (scalar code) that is rewritten when we unroll / peel the prolog epilog anyway. Targets like Hexagon or PPC with dedicated loop control instructions for pipelined loops don't need this, but

Hi Alex, We've only recently managed to get the core scalable vector IR type into the codebase (so it will be present in 9.0); that allows you to write IR with scalable vector types, but there's no backend able to generate code for it yet, and as you mention no support for stepvector (or vscale). Arm will start upstreaming those soon. -Graham > On 13 Jul 2019, at 14:32, Alex Susu via

+llvm-dev Can you give a bit of background on what you're trying to address here? After reading through the discussion and seeing that this is a best effort flag, I'm not sure that a function attribute is the best way to describe this. I'm open to being convinced it is, but I'd like to hear a bit more about the use case and get broader visibility on the proposal first.

I had a phone conversation yesterday with Graham, Francesco, and Kristof. There is one more reason to go with the native type change: ARM has already written the code with the SV types, and they have patches ready to be reviewed and integrated in LLVM. As I don't want to stand in the way of getting SVE in LLVM as soon as possible, I will also support the integration of the existing patches

Hi, I'd like to fix PR19590, which is about llvm.global_ctors containing functions that end up being empty after optimization (which causes the linker to add useless init_array entries to the output binary). globalopt removes empty functions from llvm.global_ctors, but by the time the function becomes empty globalopt has already run and it doesn't run again. I'm wondering what the

Hi, I check-out the latest version of LLVM and see many failures (on Win64): ******************** 67> FAIL: LLVM :: Transforms/GlobalOpt/zeroinitializer-gep-load.ll (5518 of 7763) 67> ******************** TEST 'LLVM :: Transforms/GlobalOpt/zeroinitializer-gep-load.ll' FAILED ******************** 67> Script: 67> -- 67> W:/LLVM_org/build64/bin/Debug/opt.EXE <