similar to: [LLVMdev] Eliminating Unused Globals

On Tue, May 10, 2016 at 11:45 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Mon, May 9, 2016 at 4:42 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> >> >> On Mon, May 9, 2016 at 4:26 PM, David Blaikie <dblaikie at gmail.com> wrote: >> >>> >>> >>> On Mon, May 9, 2016 at 3:38 PM, Peter

Dear r-devel list members, By placing a call to the new (with R 2.15.1) globalVariables() in the development version of the Rcmdr package, I've succeeded in reducing the "notes" produced by R CMD check from dozens to two. But I still get the following notes, even though '.commander.done' is in the call to globalVariables(): ------------- snip ------------ * checking R code

Hi Folks, Looking into some other issues, I came across a couple of oddities with regard to debug info for global variables (PR39900 <https://bugs.llvm.org/show_bug.cgi?id=39900> and PR39899 <https://bugs.llvm.org/show_bug.cgi?id=39899>). But a broader question I was wondering if it was anyone's radar (it's not something I'll be pushing on myself in the near future, but

On Mon, May 9, 2016 at 4:26 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Mon, May 9, 2016 at 3:38 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> >> >> On Mon, May 9, 2016 at 3:17 PM, Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> >>> >>> On Mon, May 9, 2016 at 2:33 PM,

Talked to Eric Fri and he suggested that this might be the first of several places where we want behavior of LTO compiles to diverge from normal -O2 compiles. So for now I have implemented this such that we pass down -flto to the -cc1 job, and that gets propagated as a code gen option and into the PassManagerBuilder. I have left the current logic translating -flto to the -emit-llvm-bc option,

My module contains one function that calls a handful of functions in another module (which contains a huge collection of functions). The goal is to make the module 'self-contained', i.e. no calls across module boundaries, and as minimal as possible, i.e. it does not contain any function which is not called directly or indirectly from the original function. So, I linked in the callee

On Thu, Jun 4, 2015 at 3:58 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > Personally, I think the right approach is to add a bool to > createGlobalDCEPass defaulting to true named something like > IsAfterInlining. In most standard pass pipelines, GlobalDCE runs after > inlining for obvious reasons, so the default makes sense. The special case > is

On Mon, Jun 8, 2015 at 11:33 AM, Reid Kleckner <rnk at google.com> wrote: > The clang patch lgtm, and I had some comments on the LLVM patch. Duncan, do > you want to say more there? > > --- include/llvm/Transforms/IPO/PassManagerBuilder.h (revision 237590) > +++ include/llvm/Transforms/IPO/PassManagerBuilder.h (working copy) > @@ -121,6 +121,7 @@ class PassManagerBuilder {

In order to handle a large vector based math library I link in a fairly large bitcode file that might or might not be needed. The problem is that linking in this bitcode file drastically increases the amount of compile time required. Is there a way to remove all functions that are not used after this linking pass? Something similar to die but removes functions from the compilation unit instead of

I thought this pass would do it, but when I run it over my bc file the output file is the same as the input file. The issue I guess is a little different. When I link in the huge bc file with the tiny bc file, I only want the resulting bc file to have the function definitions that the tiny bc file requires and not every function in the huge bc file. Any idea's how to do this with the

Hi I create a simple bytecode file with clang -c -emit-llvm test.c -o test.bc #include <stdio.h> void hello(){ printf("hello\n"); } void hello2(){ printf("hello2\n"); } Then i want to keep only the hello function so i do : llvm-extract -func=hello -o test2.bc test.bc but the string constants are removed and "@.str" is marked as external @str

On Thu, Jun 4, 2015 at 5:33 PM, Reid Kleckner <rnk at google.com> wrote: > On Thu, Jun 4, 2015 at 5:17 PM, Teresa Johnson <tejohnson at google.com> wrote: >> >> Agreed. Although I assume you mean invoke the new pass under a >> ThinLTO-only option so that avail extern are not dropped in the >> compile pass before the LTO link? > > > No, this pass

On May 5, 2009, at 3:48 PM, Villmow, Micah wrote: > In order to handle a large vector based math library I link in a > fairly large bitcode file that might or might not be needed. The > problem is that linking in this bitcode file drastically increases > the amount of compile time required. Is there a way to remove all > functions that are not used after this linking pass?

On OS X (10.6.2) running on an Intel Core 2 duo with LLVM 2.7 pulled about a month ago from CVS and built in debug mode: Using the JIT system with exception handling, I am having issues with type infos. "Finally" code (llvm.eh.selector intrinsic call with 0) works fine (correct landing pads found), as does this call with one type info. My type infos are each 64 bit array GlobalVariables

On Wed, Dec 5, 2018 at 4:14 PM Adrian Prantl <aprantl at apple.com> wrote: > > > > On Dec 5, 2018, at 3:58 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > Hi Folks, > > > > Looking into some other issues, I came across a couple of oddities with > regard to debug info for global variables (PR39900 and PR39899). > > > > But a

Hi Ralf, > I am trying to replace a global variable with a constant. You should be able to replace the initializer for the global with your constant, mark it as having internal linkage and then run some optimization pass over it to do the rest (not sure which one it was again, probably some constant propagation or global value optimization). That pass would then probably do some similar

On Monday 15 June 2009 01:32, me22 wrote: > My (possibly faultly) understanding is that intel's has good support > for numerics, presumably through auto-vectorization and such, but only Yes, that's true. > works for intel's architectures and is only excellent on intel chips. That used to be the case, but not so anymore. Intel compilers generate just fine code for AMD

Andrew Haley <aph at redhat.com> writes: > Óscar Fuentes wrote: >> The following message is a courtesy copy of an article >> that has been posted to gmane.comp.compilers.llvm.devel as well. >> >> Andrew Haley <aph at redhat.com> writes: >> >>> This is x86_64. I have a problem where an absolute memory load >>> >>> define

In a pass I would like to insert a ICmpInst/BranchInst pair to check if 2 GlobalVariables are equal or not. If they are not I would like to call a function. I've tried splitting the current block and then inserting before the existing instructions, but for some reason this seems to ruin the iterator(i). What is the correct way todo something like this? void checkShadowPtr(Module &M,

Hello, (Dear Richard, I hope you don't mind being Cc:'d on this thread in R-devel. This is one of the ways we can prevent similar problems from happening in the future.) Sometimes, package authors who use both exportPattern('.') and utils::globalVariables(...) get confusing WARNINGs about undocumented exports: https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010531.html I