similar to: [LLVMdev] PRE optimization in LLVM

Greetings, (I am reposting this email of mine, as I was informed that emails from the domain 'iith.ac.in' are sometimes being marked as spam) I am Aradhya Biswas, final year student of Computer Science and Engineering at Indian Institute of technology Hyderabad (IITH), and as mentioned in my previous email on the LLVM dev mailing list, I am interested to work towards the improvement of

Yeah, there's a lot of things this could be. On the memdep side: Note that memdep is not actually properly updated in all cases by most passes that claim to not invalidate it (they don't invalidate dependent pointers, only pointers they directly touch). There's already a bug filed about this. So far we've only seen missed-opt, not wrong code from this. But it should be possible

The GVN algorithm used in LLVM currently (I'm rewriting it) is the basic hash based RPO algorithm. The new one i'm writing is based on http://dl.acm.org/citation.cfm?id=512536 (see https://github.com/dberlin/llvm-gvn-rewrite) LLVM has different algorithms for both scalar PRE and load PRE. They are basically variants of standard PRE algorithms transformed into SSA, but with some

Hello everyone I am Rakshit Singla, a third year undergrad at IIT Hyderabad, India. I finished a basic compilers course last semester and am currently doing a compiler optimizations course. I have been exploring LLVM for the past few months (wrote a front-end for the Classroom Object Oriented Language and have been studying pieces of code.) I would like to work with LLVM and contribute to the

> Given what you are saying, you are also suggesting we are not rematerializing addressing computations where it is cheaper to do so. That seems pretty critical to good RA :P Yep, about 5 months ago I had a conversation about this too... it may even be the one you're referencing. Our remat is really conservative - it only rematerializes values that have zero input operands (move immediate

Hi, I am Jill, I'm new here and new with llvm. I find that its old PRE.cpp has been removed from llvm-1.9 and the project homepage says that a GVN-PRE pass is being implemented. Since many PRE algorithms have been suggested, and I think PRE further differs according to the specific defination of equivalence, whether it is an "optimal" algorithm and optimal at what metric, etc, can I

Hi, I've stumbled upon a case where I think gvn does a bad (wrong) optimization. It's a bit messy to debug though so I'm not sure if I should just write a PR about it a let someone who knows the code look at it instead. Anyway, for the bug to trigger I need to run the following passes in the same opt invocation: -sroa -instcombine -simplifycfg -instcombine -gvn The problem

On Fri, Nov 25, 2011 at 6:41 AM, josey's...JJ frm kollam nw @ calicut.... <joseykollam at gmail.com> wrote: > i wish to develop llvm SSAPRE compiler optimization for my engineering > academic project .for,that i have a sample c++ program and its .ll > file.anyone have SSAPRE implementation in c++. if anyone have, please give > me that implementation immediately. In the old

On Wed, Nov 16, 2016 at 2:03 AM, David Chisnall via llvm-dev < llvm-dev at lists.llvm.org> wrote: > This is really great to see, as I’ve spent far too much of my life over > the past two years fighting with undocumented assumptions made by GVN. A > couple of quick questions about the new GVN, based on problems I’ve had > with the old one: > > Does it assume that it’s

That should be literally impossible, which makes me think something was tested wrong The second patch i posted disables scalar pre (assuming you use -disable-pre) but not load pre. Since the patch you reverted touched only scalar pre, disabling scalar pre should *also* do the same thing. On Thu, Jul 16, 2015 at 5:43 PM, Lawrence <lawrence at codeaurora.org> wrote: > Hi, Daniel: >

On Thu, Aug 7, 2008 at 3:13 PM, David Greene <dag at cray.com> wrote: > On Tuesday 05 August 2008 13:27, David Greene wrote: > >> Neither solution eliminates the need for instcombine to be careful and >> consult masks from time to time. >> >> Perhaps I'm totally missing something. Concrete examples would be helpful. > > Ok, so I took my own advice and

I'm working on the across the subprogram call optimization, and let's say the following llvm IR, @ng0 = internal global [2 x i32] [i32 2, i32 0], align 4 %t7 = alloca [16 x i8], align 16 %add.ptr = getelementptr inbounds i8* %t1, i64 40 %call = call i8* @handle_value(i8* %add.ptr, i32 3) #3 %arraydecay = getelementptr inbounds [8 x i8]* %t3, i64 0, i64 0 %arraydecay1 =

On Wed, Jul 15, 2015 at 1:10 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > IMHO, This doesn't make a lot of sense to turn off this part on it's own. > I would just use the enable-pre flag to turn off scalar PRE, as it > will cause the same issue in other cases as well. > Is there some reason you aren't just doing that? > I suspect if this is a performance

Dear All, I'm getting the following assertion: llvm-ld: /home/vadve/criswell/src/llvm22/lib/VMCore/Value.cpp:175: void llvm::Value::setName(const char*, unsigned int): Assertion `getType() != Type::VoidTy && "Cannot assign a name to void values!"' failed. It seems to be caused by the following line in lib/Transforms/Scalar/GVN.cpp (line 1566):

On Tue, May 24, 2011 at 8:35 AM, roy rosen <roy.1rosen at gmail.com> wrote: > 2011/5/24 Justin Holewinski <justin.holewinski at gmail.com>: > > On Tue, May 24, 2011 at 3:02 AM, roy rosen <roy.1rosen at gmail.com> wrote: > >> > >> Hi, > >> > >> I was wondering if LLVM supports predicates and conditional execution. > >>

On Wed, 21 May 2008, Nicolas Capens wrote: > Thanks for the detailed explanations. I have a few remaining questions: > > Am I correct that ScalarReplAggregates is hardly more expensive than Mem2Reg > and therefore generally preferable? Right. > What would be the code quality implications of using "-dce -simplifycfg" > instead of -adce? As far as I understand the

Hi Rob, > I'm using the gvn pass, not sure about basic-aa. if you are using LLVM from svn then you need to specify the basic-aa analysis, otherwise gvn won't unify calls to readonly/readnone functions. This is new behaviour introduced by Dan; probably the tutorial should be updated. Ciao, Duncan. > > I've copied the code as-is from

2011/5/24 Justin Holewinski <justin.holewinski at gmail.com>: > On Tue, May 24, 2011 at 3:02 AM, roy rosen <roy.1rosen at gmail.com> wrote: >> >> Hi, >> >> I was wondering if LLVM supports predicates and conditional execution. >> Something like we have in IA64. >> There is a register class of predicates and then every instruction may >> be

On Fri, Jul 14, 2017 at 10:54 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > >> I think you're done when you get everything that you have that fits into >> a model of local transformations and that should be run to a fixed point. >> > > Sure, but to point out what you certainly already know, that's almost > every optimization you can think of

Hi, Daniel: Thanks a lot for detailed background information, we are willing to provide the right fix, however it will take time, do you mind if you forward me the discussion you had 5 months ago? I may not be able to access it since I only joined ellvmdev list this week. I did some performance measurement last night, some of our critical benchmark degraded up to 30% with your patch, so we have