similar to: [LLVMdev] global optimizer precision

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

The code excerpt is from IPO/GlobalOpt.cpp // If this is a first class global and has only one accessing function // and this function is main (which we know is not recursive we can make // this global a local variable) we replace the global with a local alloca // in this function. // // NOTE: It doesn't make sense to promote non single-value types since we // are

rpeng@jhsph.edu wrote: > I get different behavior on Linux: > > system("mkdir newdir") > dir("newdir", all.files = TRUE, recursive = TRUE) ## R hangs The point is that all.files=TRUE implies returning also "." and ".."! Hence the recursion uses to be infinite (from "." to "." to "." ......). If recursiv = TRUE,

Hi We have applied the routing patches from http://www.ssi.bg/%7Eja/#routes. To 2.6.15 this seems to have broken our output natting. Has anyone else experienced this or any advice on how to fix. Is this working on the newer kernel i.e. 2.6.19 ? Any help would be appreciated. -- Tim Haak email: tim@haak.co.uk cel: 0837787100 First love is only a little foolishness and a lot of curiosity,

Hi, I am currently in the process of migrating from RH 7.3 to RHEL ES 3.0 on my system. Of course there is a lot of iles that will need to change server (new server is ready). My question is of course what is the best way to do this? My thought is rsync with a function like this: 1: Running rsync once to get all the files over to my new system 2: Running rsync several times to keep the files

Hello, I am working on the the "Global Variable Optimizer" pass. I'd like to modify this pass to be more aggressive. Therefore I need the call graph. The call graph contains AssertVHs of all functions. If the "Global Variable Optimizer" pass identifies a function to be delete able it will be deleted immediately by this pass. The call graph is not destroyed before.

Hello, I had a look at the global variable optimizer. In my opinion it handles a few special cases, when global variables can be replaced by local variables or be removed completely. Basically I think that this problem could be solved with an interprocedural live value analysis for global variables more generally. An assignment to a global variable can be removed, if this global variable is dead

I just got the CVS version of LLVM running tonight. On my PowerBook, one of the examples (HowToUseJIT) has an assertion error when I try and run it: Running foo: JIT.cpp:217: failed assertion `!isAlreadyCodeGenerating && "Error: Recursive compilation detected!"' However, when I compile and run the same program on x86 Linux, it runs fine (Running foo: Result: 11). I

On Feb 20, 2005, at 11:12, Evan Jones wrote: > I can "fix" it by changing JITResolver::getFunctionStub to use > F->isExternal() instead of F->hasExternalLinkage(). However, this then > breaks when calling *real* external functions (native code). I obviously should not post to mailing lists before I've eaten. With my "fix" I get an assertion when taking an

Hi, I've been able to link ioquake, but not without a small modification to lib/Linker/LinkModules.cpp:427 where I had to add: } else if (Dest->hasExternalLinkage() && Src->hasExternalLinkage()){ LinkFromSrc = true;//overwrite old value LT = Src->getLinkage();//use src linkage The reason is that two files both had a global function pointer variable (due

On Jan 12, 2009, at 8:24 AM, Dan Gohman wrote: > > On Jan 11, 2009, at 11:22 AM, Chris Lattner wrote: > >>>> There is no good reason for malloc to be an instruction anymore. >>>> I'd >>>> be very happy if it got removed. Even if we keep it, malloc/alloca >>>> should be extended to optionally take 64-bit sizes. >>> >>>

On Jan 11, 2009, at 11:22 AM, Chris Lattner wrote: >>> There is no good reason for malloc to be an instruction anymore. >>> I'd >>> be very happy if it got removed. Even if we keep it, malloc/alloca >>> should be extended to optionally take 64-bit sizes. >> >> I'm curious. Do we want to keep the free instruction? > > No,

Chris Lattner wrote: > On Jan 12, 2009, at 8:24 AM, Dan Gohman wrote: > >> On Jan 11, 2009, at 11:22 AM, Chris Lattner wrote: >> >>>>> There is no good reason for malloc to be an instruction anymore. >>>>> I'd >>>>> be very happy if it got removed. Even if we keep it, malloc/alloca >>>>> should be extended to

On 23.04.2013 19:10, Gao, Yunzhong wrote: > I missed the discussion when I implemented dllexport/dllimport for our local tree. I > essentially implemented your approach#1. I was trying to avoid the various > external_linkage + some_attribute approaches because it seems that external_linkage > would imply the external linkage without the dllimport/dllexport semantics, and there > may

Hi Nico, Thank you for your feedback. I'll try to answer your questions below. > What problems do you expect with another approach? I have a local > prototype that removes dllimport/export as linkage and uses function > attributes and an extension to globals. I decorate dllexported functions with > the Used attribute and it seems to work fine. This allows such functions to >

Hi developers, I have some problems using a non-default alias analysis. I wrote a modulepass which needs a functionpass. The functionpass needs a type bases alias analysis instead of the basicaa. I added the command line parameter for this analysis to the opt invocation as follows: opt -tbaa -global-live-values test.bc The 'global-live-values' pass preserves all and requires a

Hi LLVM-Developers, I am looking for an analysis which figures out, if via function argument dereferencing a given value can be modified within that function. Or stated differently: Is in a called function an alias to a given value being modified? The current Basic Alias Analysis seems not to support values in different scopes, so I can't use it for this purpose. Is it supported by a

Dear LLVM developers, I have a question regarding the IPSCCP class and the handling of dead blocks: The file lib/Transforms/Scalar/SCCP.cpp of llvm 2.8 from contains some code to deal with a dead block which could not be folded (line 1909ff). This happens when a user of this dead block is a branch or switch with an undef condition. The action taken than is to replace this terminator with an

Hi Nico, Reid, and Anton, I missed the discussion when I implemented dllexport/dllimport for our local tree. I essentially implemented your approach#1. I was trying to avoid the various external_linkage + some_attribute approaches because it seems that external_linkage would imply the external linkage without the dllimport/dllexport semantics, and there may be existing compiler codes that rely on

> My primary concern is what needs to be added to preserve current > compiler behavior where necessary. All the other approaches appear > to involve adding flags or attribute to an existing linkage type, so any > existing compiler codes that deal with that particular linkage type will > potentially have different behavior. Right. But normally LLVM API does not provide backward