similar to: Benchmark GlobalsModRef in non-LTO pass pipeline

Hi Chandler, I would like to run some benchmarks on ARM hardware and to look at impact of your patches on LTO. Kind regards, Evgeny Astigeevich From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chandler Carruth Sent: 15 July 2015 10:45 To: Chandler Carruth; Gerolf Hoflehner Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] GlobalsModRef

Replying here, but several of the questions raised boil down to "couldn't you make the usage of GetUnderlyingObject conservatively correct?". I'll try and address that. I think this *is* the right approach, but I think it is very hard to do without effectively disabling this part of GlobalsModRef. That is, the easy ways are likely to fire very frequently IMO. The core idea is

Can you say what Benchmark or give a test case so we understand the nature of the regression? As Gerolf said, that will be important to understand what is best to do. On Fri, Jul 17, 2015, 06:43 Evgeny Astigeevich <Evgeny.Astigeevich at arm.com> wrote: > Yes, the regression is stable. I double checked this. A full benchmark > run consists of at least 10 sub-runs to validate the

Before the fix, the compiler may simply return 'noalias' for cases it can not really prove to be noalias, but actually correct by luck (or even wrong noalias, but does not result in miscompile). It would be useful to find out the set of missed noalias queries from GlobalModRef with your benchmark and examine if there is some improvement can be done. David On Fri, Jul 17, 2015 at 6:32

Hey, thanks for benchmarking. How stable is the 2% regression? Michael ran some benchmarks with GlobalsModRef completely disabled and the only differences were in the noise. This was a complete spec2k6 run along with some others. Based on the number of benchmarks run there, I'm going to go ahead and submit these patches, but if you can clarify the impact here, we can look at potentially some

On Fri, Jul 17, 2015 at 9:13 AM Evgeny Astigeevich < evgeny.astigeevich at arm.com> wrote: > It’s Dhrystone. > Dhrystone has historically not been a good indicator of real-world performance fluctuations, especially at this small of a shift. I'd like to see if we see any fluctuation on larger and more realistic application benchmarks. One advantage of the flag being set is that we

On Mon, Jul 13, 2015 at 10:21 PM Chris Lattner <clattner at apple.com> wrote: > > > On Jul 13, 2015, at 8:19 PM, Chandler Carruth <chandlerc at gmail.com> > wrote: > > > > Ok folks, > > > > I wrote up the general high-level thoughts I have about stateful AA in a > separate thread. But we need to sort out the completely and horribly broken >

Based on function names and structures, this is some version of GCC :) Any way you can post the entire .ll file? Because it's globalsmodref, it's hard to debug without the other functions, since it goes over all the functions to determine address takenness, etc :) On Tue, Jul 21, 2015 at 3:23 PM, Michael Zolotukhin <mzolotukhin at apple.com> wrote: > Hi Chandler, > > We

----- Original Message ----- > From: "Chris Lattner" <clattner at apple.com> > To: "Chandler Carruth" <chandlerc at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov>, "Justin Bogner" > <mail at justinbogner.com>, "Duncan Exon Smith"

Ok folks, I wrote up the general high-level thoughts I have about stateful AA in a separate thread. But we need to sort out the completely and horribly broken aspects of GlobalsModRef today, and the practical steps forward. This email is totally about the practical stuff. Now, as to why I emailed this group of people and with this subject, the only pass pipeline that includes GlobalsModRef, is

Hi there, I am doing: opt -print-memdeps ./test.bc -analyze -globalsmodref-aa by adding globalsmodref-aa, I am hoping that globalsmodref alias analysis will be used. However, it does not turn out to be so. I found this out by adding some "errs() << " into the source code for that alias analysis. So my question is what should I do to let memory dependency analysis use

Hi all, I'm implementing an intra-procedural analysis. For correctness, during the analysis of each function I need to know which global variables may be modified by other functions in order to avoid wrong assumptions about those variables. I looked at lib/Analysis/IPA/GlobalsModRef.cpp and it seems that it does what I want. My problem is that I don't know how to use it ;-( I wrote a

Hello I am trying to enable globalsmodref-aa by default. globalmodref-aa is a ModulePass and therefore can be invalidated and need to be rerun. I see globalsmodref-aa is enabled in LTO passmanager by adding the analysis pass explicitly. I wonder whether globalsmodref-aa can be enabled/run based on pass dependencies, i.e. those indicated in getAnalysisUsage(). Thanks, Xin -------------- next

Hi Jorge, > I'm implementing an intra-procedural analysis. For correctness, during > the analysis of each function I need to know which global variables > may be modified by other functions in order to avoid wrong assumptions > about those variables. > > I looked at lib/Analysis/IPA/GlobalsModRef.cpp and it seems that it > does what I want. My problem is that I don't

Is there anyway I can write a script which feed input datasource from stdin and let R process it (maybe frequency report) then output the report to stdout? I can't seem to find much info on documentation or FAQ on this topic. Thanks! Soichi Hayashi ********************************************************************** The information contained in this communication is confidential,

Hi, In my pass, I want to use the alias-analysis info provided by "GlobalsModRef". How should I use "getModRefBehavior(...)"-method and "alias(...)", in order to get the best presicion? More precisely, how can I find the required arguments, particularly "PointerAccessInfo", for this methods. And is it a good idea to use "GlobalsModRef" in the

"Daniel Stewart" <stewartd at codeaurora.org> writes: > I'm no expert on the PassManager, but I happen to be going through it > fairly carefully right now. You didn't state which passes were Module > Passes and which were Function Passes (or other types). Sorry, I did mean to include that. They are all FunctionPasses. > One thing I have noticed is that

I've patched R so that it can be used as a scripting language, i.e. you can (on Unix-like systems) write files containing R code and execute them non-interactively, e.g.: #!/usr/local/lib/R/bin/R.bin --script cat("Hello World!\n") I've updated the patches for R-1.7.0; if you're interested in the patches, e-mail me at mckay@gmr.com, and I'll send them to you. --

Hello, I'm playing with alias analysis, using the following program: %i = external global int ; <int*> [#uses=2] implementation ; Functions: int %_Z3bari(int %p) { entry: %tmp.0 = load int* %i ; <int> [#uses=1] %tmp.1 = setgt int %tmp.0, 10 ; <bool> [#uses=1] br bool %tmp.1, label %then, label %UnifiedReturnBlock then:

Greetings folks, As I'm working on refactoring the AA interfaces in LLVM to prepare for the new pass manager, I keep hitting issues. Some of the complexity that is hitting this stems from the update API, which consists of three virtual functions: deleteValue(Value *V) copyValue(Value *From, Value *To) addEscapingUse(Use &U) These interfaces are *very* rarely called. Here are the only