similar to: [LLVMdev] Fwd: [Review Request][PATCH] Add the function "vectorizeBasicBlock"

Ether, Sounds great! Please keep in mind that, eventually, we'll also want to configure those options from TLI (or something similar). The patch looks good to me. -Hal On Wed, 4 Apr 2012 23:54:18 +0800 Hongbin Zheng <etherzhhb at gmail.com> wrote: > Hi Hal, > > I add a function named "vectorizeBasicBlock" which allow users to > perform basic block

On 11/23/2011 05:52 PM, Hal Finkel wrote: > On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: >> > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: >>> > > Tobias, >>> > > >>> > > I've attached an updated patch. It contains a few bug fixes and many >>> > > (refactoring and coding-convention) changes inspired

Tobias, I've attached an updated copy of the patch. I believe that I accounted for all of your suggestions except for: 1. You said that I could make AA a member of the class and initialize it for each basic block. I suppose that I'd need to make it a pointer, but more generally, what is the thread-safely model that I should have in mind for the analysis passes (will multiple threads

On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > > Tobias, > > > > I've attached an updated patch. It contains a few bug fixes and many > > (refactoring and coding-convention) changes inspired by your comments. > > > > I'm currently trying to fix the bug responsible for causing a compile

On Fri, 2011-12-02 at 17:07 +0100, Tobias Grosser wrote: > On 11/23/2011 05:52 PM, Hal Finkel wrote: > > On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: > >> > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > >>> > > Tobias, > >>> > > > >>> > > I've attached an updated patch. It contains a few bug fixes

On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > Tobias, > > I've attached an updated patch. It contains a few bug fixes and many > (refactoring and coding-convention) changes inspired by your comments. > > I'm currently trying to fix the bug responsible for causing a compile > failure when compiling >

On 11/17/2011 12:38 AM, Hal Finkel wrote: > Tobias, et al., > > Attached is the my autovectorization pass. Very nice. Will you be at the developer summit? Maybe we could discuss the integration there? Here a first review of the source code. > diff --git a/docs/Passes.html b/docs/Passes.html > index 5c42f3f..076effa 100644 > --- a/docs/Passes.html > +++ b/docs/Passes.html

Hi everyone, I downloaded the latest version of LLVM PTX backend from http://www.prog.uni-saarland.de/projects/anysl and made the required changes to all the files mentioned in the README. But I get the following error when I compile it. llvm[3]: Compiling PTXBackend.cpp for Release build In file included from PTXBackend.h:70:0, from PTXBackend.cpp:36: PTXPasses.h: In constructor

Hi Everyone, I propose that we remove BBVectorize from trunk. Here's why: - It never made it from "interesting experiment" to "production quality" (it is not part of any in-tree optimization pipeline). - We now have an SLP vectorizer that we do use in production, had have for some time. - BBVectorize otherwise needs refactoring, and the implementation has lots of

If I run: opt -globals-aa -die -inline -debug-pass=Details foo.ll -S then I will get this pass structure: Target Library Information Target Transform Information Target Pass Configuration Assumption Cache Tracker Profile summary info ModulePass Manager CallGraph Construction Globals Alias Analysis FunctionPass Manager BasicBlockPass Manager Dead Instruction

ether zhhb wrote: > hi John, > > sorry for reply so late. > > On Tue, Apr 13, 2010 at 10:38 PM, John Criswell <criswell at uiuc.edu > <mailto:criswell at uiuc.edu>> wrote: > > Devang Patel wrote: > > On Mon, Apr 12, 2010 at 6:41 PM, ether zhhb > <etherzhhb at gmail.com <mailto:etherzhhb at gmail.com>> wrote: > >

On Feb 17, 2013, at 1:15 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> Unrolling OTOH should be aware of and preserve any loop metadata. > > If the unroller somehow differentiates the metadata coming from different loop iterations, then BBVectorize can use this information as well. Even better, we could make BasicAA understand that appropriately marked loads and stores from

Well, do you have a patch that enables the new pass manager that we can land then? To be more serious: 1) I don't even know how to run those passes using the new pass manager even if it where enabled by default. I guess that I'm supposed to use -passes. Is there a syntax description for that option somewhere? How do I for example run -die? 2) "Use the new pass manager" does

I'm not sure about the old pass manager, but I think the new pass manager solves this issue. See llvm::updateCGAndAnalysisManagerForFunctionPass where it updates the call graph to be in sync with edges deleted by function passes. So I suspect the right fix is to use the new pass manager. -- Sanjoy On Mon, May 7, 2018 at 7:32 AM, Björn Pettersson A via llvm-dev <llvm-dev at

Hello, After investigating PR14133, I've discovered that jump threading can output self-referential instructions: %inc.us = add nsw i32 %inc.us, 1 At least in the test case for that bug report, the relevant code is later deleted (perhaps it is unreachable), and so this does not cause a problem. Unfortunately, when vectorization is enabled, this instruction causes BBVectorize to hang. Should

Hi Björn, 1) The pass pipeline syntax is documented here: https://github.com/llvm-project/llvm/blob/master/include/llvm/Passes/PassBuilder.h#L378 -die is not implemented, since the new pass manager does not support BasicBlock passes. But you can use dce instead: "-passes=dce" 2) I don't have a qualified answer here, but if I recall correctly, the trouble to correctly update the

Hi Hal, > After investigating PR14133, I've discovered that jump threading can output self-referential instructions: > %inc.us = add nsw i32 %inc.us, 1 such instructions are valid in unreachable basic blocks. > At least in the test case for that bug report, the relevant code is later deleted (perhaps it is unreachable), and so this does not cause a problem. Unfortunately, when

On Mar 17, 2010, at 11:25 AM, David Greene wrote: > On Monday 15 March 2010 13:45:14 David Greene wrote: >> On Sunday 14 March 2010 18:32:35 Chris Lattner wrote: >>> This is much better than the first iteration but still has many issues. > > I believe I've addressed all your points with this patch except I didn't use > StringRef. It doesn't appear to be

I've just had some fun, because I wanted to override FunctionPass::addAnalysisUsage, but forgot "const" after the method name -- so instead of overriding I've just created a new unrelated method. After spending some time on this, I've decided to add -Woverloaded-virtual option to compiler to catch such cases. However, it also gives some warnings on LLVM code:

On 02/17/2013 11:15 PM, Hal Finkel wrote: > If the unroller somehow differentiates the metadata coming from different > loop iterations, then BBVectorize can use this information as well. Even > better, we could make BasicAA understand that appropriately marked loads > and stores from different iterations don't alias. Then the AA-based > dependency breaker in the scheduler could