similar to: AA pass dependencies

On Wed, Jan 2, 2019 at 1:34 AM Markus Lavin <markus.lavin at ericsson.com> wrote: > To be more specific I am trying to use LVI from inside BasicAA to improve > some cases that turned out to be relevant for our downstream target. > > > > The code is in https://reviews.llvm.org/D55107 and I have problems with a > failing assert in the LazyValueInfoWrapperPass destructor

The management of passes in the legacy PM is ... highly confusing. Do you have a specific problem you're trying to solve or a specific question? On Thu, Dec 27, 2018 at 6:47 AM Markus Lavin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > > Looking at the output of e.g. > > > llc -mtriple=x86_64-unknown-linux-gnu test/CodeGen/X86/pre-coalesce.ll >

Hi, I am trying to call LowerSwitchPass directly in my custom pass in this way: FunctionPass *lower = createLowerSwitchPass(); lower->runOnFunction(*f); But it will crash when running lower->runOnFunction(*f) in llvm-9. I was using this method in llvm-8 and it worked fine. It seems the crash happens at the first line of the LowerSwitch::runOnFunction(Function &F) in the newer

There is no “switch” instruction in the target object code. It usually gets compiled into a switch table with instructions to load from it. Afaik Zhang > 在 2019年12月26日，17:49，n3v3rm03 via llvm-dev <llvm-dev at lists.llvm.org> 写道： > > Sorry I found an early thread discussing this question. I guess I shouldn't create lower switch pass like this. > However, I have another

On Mon, Aug 7, 2017 at 2:14 AM, Anastasiya Ruzhanskaya via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I am trying to print it like this (maybe here is smth wrong?) > > > LazyValueInfo &LV = getAnalysis<LazyValueInfoWrapperPass>().getLVI(); > DominatorTree &DT = > getAnalysis<DominatorTreeWrapperPass>().getDomTree(); > LV.printLVI(F,

Hello, I am trying to figure out, what vrp propagation does in llvm. I tried this program: #include <stdio.h> int main() { int s = 0; int j = 0; for (int i = 0; i < 100; i++) { j = j+i+1; s+=j; } return (s+j); } And got this under optimized version ( I don't want everything to be eliminated) define i32 @main()

Fedor, Yes that is what happens in my case that the loop is fully unrolled and hence ‘removed’. My objection though is that there is still IR that could be dumped (i.e. the function containing the loop that was removed or the entire module) and that is what I want to have dumped after each pass when I specify -print-after-all. Of course there may be certain implementation details that could make

add -basicaa to your command line :) On Mon, May 11, 2015 at 7:15 AM, Willy WOLFF <willy.mh.wolff at gmail.com> wrote: > I play a bit more with MemoryDependenceAnalysis by wrapping my pass, and > call explicitely BasicAliasAnalysis. Its still using No Alias Analysis. > > How can I let MemoryDependenceAnalysis use BasicAliasAnalysis? > > Please, find attached my pass. >

Hi, As part of new pass manager work, I've been trying to get something like `opt -foo` working under the NPM, where `foo` is the name of a pass. In the past there's been no reason to keep the names of passes consistent between NPM and legacy PM. But now there is a reason to make them match, so that we don't have to touch every single test that uses `opt`. There are a couple of

After playing a bit with the newly introduced hardware loop framework I realize that the llvm.set.loop.iterations intrinsic takes as argument the number of iterations the loop will execute. In fact it goes all the way to, on IR, insert an addition of constant 1 to the number of taken backedges returned by SCEV. If the machine instruction realizing the loop is interested in the number of

TL;DR: I'm looking to have AliasAnalysis passes have the ability keep a temporary cache when no transformations are performed. I'm interested to first and foremost clarify what is the best way to even start such an infrastructure change, such that it is not abused (or even available) by other passes. We certainly don't want to keep arbitrary caches in all passes. Would making this a

Hello. This question has come up in https://reviews.llvm.org/D70043 There, i'm teaching ConstantRange how no-wrap flags affect the range of `mul` instruction, with end goal of exploiting this in LVI/CVP. There are certain combinations of ranges and no-wrap flags that result in always-overflowing `mul`. For example, `mul nuw nsw i4 [2,0), [4,0)` always overflows:

Hi Hal, Yes, the "internal" caches AA would be valid as long as the IR is not mutated. Are you suggesting keeping them? It's possible, but it will be very tricky to ensure they are cleared at the right times and they will likely be prone to adding hidden bugs. I don't have strong indications currently that keeping such information would be useful by other users, other than

On Sat, Dec 17, 2016 at 8:39 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > >>> >> LVI is one of those analyses with quadratic runtime, but has a cutoff to >> its search depth so that it is technically not quadratic. So increased >> inlining could easily exacerbate it more than non-"quadratic" passes. >> (increased inlining would also cause

On 2/10/20 2:35 PM, Alina Sbirlea wrote: > Hi, > > Here's a tentative patch of the changes for this: D74353 > <https://reviews.llvm.org/D74353>. I suppose that, as expected, it's invalidated less often this way. Given that it's generally stateless, does this really represent a cost savings?  -Hal > > Thank you, > Alina > > > On Mon, Feb 10,

Hi, I try to use MemoryDependenceAnalysis in a pass to analyse a simple function: void fct (int *restrict*restrict M, int *restrict*restrict L) { S1: M[1][1] = 1; S2: L[2][2] = 2; } When I iterate over MemoryDependenceAnalysis on the S2 statement, I get the load instruction for the first depth of the array, that’s ok. But I get also the load and store for the S1 statement. I assume the

Hi guys, I have an analysis that is able to answer questions like this: given an integer variable, what is the interval of values that this variable can assume during the program's execution? I want to integrate this analysis into LLVM and it seems LVI (Lazy Value Info) is the best place to do this kind of stuff. Can someone give some hints about what I have to do to integrate my analysis

Hi, I recently worked on an issue where I realized that -print-after-all does not cover all passes run by the pass manager. E.g. it seems that loop passes are not fully covered and I could find that loop transformations showed up in the dump of the next non-loop pass (which happened to be 'Combine redundant instructions' and that was rather confusing). Specifying both -print-before-all

While building test-suite with the new PM, I ran into problems with AssertingVH being triggered which is obvious in retrospect: https://llvm.org/bugs/show_bug.cgi?id=28400 Both cases I ran into revolve around LVI which holds AssertingVH. Essentially, what happens is this: 1. LVI holds an AssertingVH pointing at a BasicBlock 2. Some other pass ends up deleting that BB (e.g. SimplifyCFG) 3. BOOM

On 2016-09-27 02:28, Philip Reames wrote: > On 09/20/2016 12:05 PM, Matti Niemenmaa via llvm-dev wrote: >> I posted some questions related to implementing inference of nsw/nuw >> flags based on known icmp results to Bug 30428 ( >> https://llvm.org/bugs/show_bug.cgi?id=30428 ) and it was recommended >> that I engage a wider audience by coming here. The minimal context is