similar to: GlobalOPT and sections

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

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

On Wed, 2 Nov 2005, Evan Jones wrote: > I am trying to generate LLVM code that references a global array. > Unfortunately, while I am generating the code I do not know the final length > of the array, as I add elements to it as my compiler goes along. What is the > best way to do this in LLVM? Ideally, I would be able to define the > GlobalVariable array and change its length

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

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:

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

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

On Wed, Jun 20, 2012 at 9:29 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> Attaching a new patch that has the behaviour we discussed. >> >> The "globaldynamic" and default values have been merged, and LLVM will >> start off with the user-specified model, but choose a more specific >> one if possible. >> >> Please review.

On Tue, Apr 4, 2017 at 12:36 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > On 2017-Apr-04, at 12:12, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >>

On Nov 2, 2005, at 16:39, Chris Lattner wrote: > 4. Replace the old GV with the new GV using code that looks like this: > > OldGV->replaceAllUsesWith(ConstantExpr::getCast(NewGV, > OldGV->getType()); > OldGV->eraseFromParent(); > > At the end of this, any instructions or other globals that referenced > the temporary global will now reference the new one.

Hi all, I had a look at the interprocedural optimizer. In my opinion the routine 'GlobalOpt::ProcessInternalGlobal' is a little bit to conservative. It removes global variables if the only routine using this variable is main. Typically this condition is valid only for very few global variables. Here is a code snippet containing the test before the transformation: file:

> 1. How to find all constants in Module? Does this code find all of them, or > they are somewhere else too? > for (GlobalVariable &GV : globals()) { > if (auto C = static_cast<Constant*>(GV.Op<0>().get())) { > ... C is Constant* > } > } Constants are unfortunately part of the Context, not the module :-( Cheers, Rafael

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

Is it possible to define lookup tables as a list in tablegen, to map one value to another? Here's the template I was working on: ========================================= class LookupTable { list<int> mapping = [0, 8, 16, 24, 32]; } def LUT : LookupTable; class MyRegister<name, index> : Register<name> { let HWEncoding = LUT.mapping[index]; int otherVal = index;

I've been through this once before, and passing the proverbial camel through the eye of the proverbial needle seemed easier. $ ./configure ... configure:20721: checking for pkg-config configure:20739: found /usr/bin/pkg-config configure:20752: result: /usr/bin/pkg-config configure:20768: /usr/bin/pkg-config couldn't find libshout. Try adjusting PKG_CONFIG_PATH. configure:20774: checking

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

On Tue, May 19, 2015 at 1:18 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Tue, May 19, 2015 at 1:05 PM, Teresa Johnson <tejohnson at google.com> > wrote: >> >> On Tue, May 19, 2015 at 12:41 PM, David Blaikie <dblaikie at gmail.com> >> wrote: >> > >> > >> > On Mon, May 18, 2015 at 9:09 PM, Teresa Johnson

We've noticed a difference in the embedded bitcode when compiling human readable IR to an object directly vs first compiling IR to BC and then an object through clang -cc1. If the original IR file contained an "llvm.compiler.used" gv, it will be preserved when compiling IR -> BC -> Obj. When compiling IR -> Obj directly, it will be removed. This difference does not exist