search for: globalopts

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

Guys, What I want to do is to hack global opt pass, which needs ScalarEvolution analysis. However opt crashed saying "opt: /home/xchen/llvm/include/llvm/PassAnalysisSupport.h:242: AnalysisType& llvm::Pass::getAnalysisID(const void*, llvm::Function&) [with AnalysisType = llvm::ScalarEvolution]: Assertion `ResultPass && "Unable to find requested analysis info"'

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 <

I talked about this with Nick in person months ago, and my understanding is that GlobalOpt is also an enabling optimization that needs to run early. For example, if we can eliminate an initializer to an internal global with no other stores to it, we can propagate the result. Maybe we should run it twice. On Thu, May 1, 2014 at 11:01 AM, Rafael Espíndola < rafael.espindola at gmail.com>

Hello everyone, This is a rather ancient code with Chris's name all over it, so I naturally feel humbled :) I see a conceptual issue in lib/Transforms/IPO/GlobalOpt.cpp with several optimizations that create a copy of GlobalVariable without copying attributes from the original one. Consider this one: http://llvm.org/doxygen/GlobalOpt_8cpp_source.html static bool

Chris, Thanks for the clarification... at least no bug report is due... and I am glad that I've asked. In my case these transformations are rather useful and forcing them to copy original global variable section is making them compatible with our (rather important) use case, so I guess I will have to fix it locally. Nevertheless if someone else would have a similar issue - I would be

[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

In a debug build you should get a stack trace by default, which would be helpful here. I can try to repro later today, but I'm not surprised there are issues because most people I know stick with 32-bit builds even on 64-bit Windows. On Mon, Apr 29, 2013 at 4:27 AM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote: > Hi, > > > > I check-out the latest version of

Guys, In this case, I wanted to hack globalopt pass to require ScalarEvolution analysis. It seems ScalarEvolution is not released after globalopt pass, and it will hold a reference to the basicblocks. Later when the function is removed(by inline pass), coredump happened: opt test.bc -mem2reg -globalopt -inline -loop-unroll -debug-pass Details -o out.bc >& log So it seems to me if a pass

On Wed, 2008-05-14 at 10:20 -0700, Chris Lattner wrote: > On Wed, 14 May 2008, Jonathan S. Shapiro wrote: > > On Wed, 2008-05-14 at 16:15 +0200, Duncan Sands wrote: > >> I don't think the logic is based on "main", but on whether functions > >> are marked "internal" or not. That said, GlobalOpt.cpp seems to reason > >> based on the name

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

I fell over this issue yesterday myself with lots of asserts being thrown. I think the issue is in lib/IR/AsmWriter.cpp:1618 in the function AssemblyWriter::printFunction(const Function *F) Looking at the code I think the 2nd for loop should be preceded by the test ... if (Idx < AS.getNumSlots()) Not sure why it doesn't fail on other platforms as it looks like it should be a genuine

> >> You can look at AddOptimizationPasses() in opt.cpp. > > > > As far as I understand, the two passmanager do not interleave their > > passes. It first runs all the function passes and below. Then all the > > module passes. So if you specify: > > > > opt -mymodulepass0 -myfunctionpass -mymodulepass1 > > > > What you actually get is:

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:

Given some code: static int x = 100; int main() { x = 101; printf("%d\n", x); } results in: %0 = load i1 %1 = select %0, 101, 100 ... ... 1) What architecture(s) does this benefit? 2) What's the best way to circumvent this in the backend (currently I am just not allowing this opt function to run)? I have tried a few setOperationAction methods to no result. Rather not just

On Wed, 14 May 2008, Jonathan S. Shapiro wrote: >> huh? > > Duncan asserted that there is a behavior in GlobalOpt.cpp that relies on > main being the single entry point. If he is mistaken, great. If he is > correct, a regression test case for this seems like a useful thing to > build. I'm not saying that somebody else should do it. In fact, it seems > like a fine way to

See bills commit and chris's revert. Please fix. Sent from phone On Apr 29, 2013 8:41 AM, "Keith Walker" <keith.walker at arm.com> wrote: > I fell over this issue yesterday myself with lots of asserts being thrown. > > I think the issue is in lib/IR/AsmWriter.cpp:1618 in the function > AssemblyWriter::printFunction(const Function *F) > > Looking at the code

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

Hello, GlobalOpt has an interesting special-case optimization for globals that are only accessed within "main". These globals are replaced by allocas within the "main" function (and the GV itself is deleted). The full condition for this happening is: // If this is a first class global and has only one accessing function // and this function is main (which we know is not