similar to: RFC: first steps toward CFG-level IR manipulation

Hi folks, For the past month I’ve been working on improving the DominatorTree and PostDominatorTree in LLVM. The RFC that explains the motivations and plans can be found here: http://lists.llvm.org/pipermail/llvm-dev/2017-June/114045.html . Here’s a short summary of what changed upstream since posting it: - We switched from the Simple Lengauer-Tarjan algorithm for computing dominators

Hi folks, I’m working on adding an API for incremental updates to DominatorTree and I noticed that there isn’t a simple way to quickly build and update CFG (just for testing) -- one has to either build CFG programmatically, or write IR by hand and manually map pointers to basic blocks. The downside is that it tends to be pretty verbose and not easy to update (e.g. adding a new edge often involves

> I'm not necessarily sympathetic to the idea of adding another canonicalization pass only for this purpose. The problem is that as you said, SimplifyCfg does all sorts of stuff, and I suspect is not the fastest pass in the world. Also, in the case that annoys me, there is an LCSSA pass in the middle, and I suspect it would be a better idea to only do the LCSSA etc. transform again if no

Hi Jakub! On Mon, 17 Jun 2019 at 17:01, Jakub (Kuba) Kuderski <kubakuderski at gmail.com> wrote: > Hi Kristóf, > > >> 1. I read the article IDFCalculator is based on[1], but I found no >> references to IDFCalculator::setLiveInBlocks, and the file header seems to >> confirm that it's an implementation specific thing. Could I get away >> restricting the

Hi Rohith, > I'm actually working on building a dependence graph . I'm not able > to find the methods which llvm uses to build the CFG. Is it possible to > use the same functions do build a dependence graph ( i Know the CFG > nodes are basicblocks where as dependence graph nodes will be variables)?. LLVM does not have explicit methods to build the CFG because it is

Hi, Is there any API within llvm that provides methods to access the CFG and do some manipulations on the CFG. Thanks, Rohith. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100317/5536c443/attachment.html>

There's already a LoopSimplifyCFG which is a loop-pass (and thus can iterate with other loop passes) and eliminates trivial branches.  Having a simple pass which just strips unreachable blocks and converts conditional branches to unconditional ones while updating appropriate analyzes (LoopInfo, DomTree, LCSSA, etc..) seems very reasonable.  This could also be a utility function called

A polite ping, could someone please share a thought about this? On Sat, 8 Jun 2019 at 21:21, Kristóf Umann <dkszelethus at gmail.com> wrote: > A polite ping on this matter :) > > On Tue, 4 Jun 2019 at 01:51, Kristóf Umann <dkszelethus at gmail.com> wrote: > >> Hi! >> >> As the title suggests, I'd like to generalize llvm::IDFCalculator to be >>

With regards Bhargav Reddy Godala Software Engineer 2 Bangalore, India E-mail: Bhargav-reddy.Godala at amd.com<mailto:Bhargav-reddy.Godala at amd.com> Ext 30678 On 23-Sep-2017, at 9:27 PM, Daniel Berlin <dberlin at dberlin.org<mailto:dberlin at dberlin.org>> wrote: On Sat, Sep 23, 2017 at 8:38 AM, Godala, Bhargav-reddy via llvm-dev <llvm-dev at

I understand that changing the starting element to “InsertedPHIs.being() + StartingPHISize” it will be finite but given that InsrtedPHIs is finite. I have a case where one element(same element is appened to InsertedPHIs) is added to InsertedPHIs every time fixupDefs is invoked. I traced the issue why this was happening. template <class RangeType> MemoryAccess

On Sat, Sep 23, 2017 at 9:55 AM, Godala, Bhargav-reddy < Bhargav-reddy.Godala at amd.com> wrote: > > With regards > Bhargav Reddy Godala > Software Engineer 2 > Bangalore, India > E-mail: Bhargav-reddy.Godala at amd.com Ext 30678 > > > > On 23-Sep-2017, at 9:27 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > > On Sat, Sep 23, 2017 at

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200320/34cdec77/attachment.html> -------------- next part -------------- Hi all, I have encountered some issues with the preservation of the location of llvm.loop metadata (containing optimisation hints), and would appreciate some feedback on the issue. The IR language description states that

My understanding is that alias analysis returns results in the function scope, not in loop scope. Since both the phis access both global arrays, that should results in BasicAA conservatively returning MayAlias. I debugged this a little bit and narrowed it down to the section of the code in BasicAAResult::aliasPHI() which has this comment- // Analyse the PHIs' inputs under the assumption

We should only add phis that were newly inserted, not ones that were already found. There are two cases we will hvae inserted phis: Part of the recursive call, or right in this function. The easiest way to differentiate new phis from old ones is whether they have 0 operands. I expect the attached will fix it. If not, please file a bug with reproducible IR. On Sun, Sep 24, 2017 at 11:40 PM,

Hi Hal, In that case what is the best way to query whether there is a loop carried dependence between B[j] and A[j] at i-loop level? We were operating under the assumption of 'conservatively correct' behavior of alias analysis in the function scope? Thanks, Pankaj From: Finkel, Hal J. <hfinkel at anl.gov> Sent: Tuesday, March 17, 2020 11:50 AM To: Hiroshi Yamauchi <yamauchi at

On Wednesday 28 January 2009 11:32, Chris Lattner wrote: > On Jan 28, 2009, at 9:06 AM, David Greene wrote: > > On Tuesday 27 January 2009 18:28, Eli Friedman wrote: > >> You can use a no-op bitcast for scalars, but there isn't any reliable > >> way to do it for all first-class values. > > > > Guh. > > > >> That said, I don't quite

SimplifyCFG FoldTwoEntryPhiNode looks to simplify all 2 entry phi nodes in a block, if it can't do them all then it won't do any and returns. There is a lot of code that is directly in this function geared toward this requirement. Is it possible currently to get this function (or pass) to simply fold "some" of the phis (without having to fold them all?). I understand that

On Feb 1, 2011, at 1:08 PM, Andrew Clinton wrote: > I have a (non-entry) basic block that contains only PHI nodes and an > unconditional branch (that does not branch to itself). Is it always > possible to merge this block with it's successor and produce a > semantically equivalent program? I'm trying to undo some of the loop > optimizations that LLVM has applied to my

I have a (non-entry) basic block that contains only PHI nodes and an unconditional branch (that does not branch to itself). Is it always possible to merge this block with it's successor and produce a semantically equivalent program? I'm trying to undo some of the loop optimizations that LLVM has applied to my program to reduce a pair of nested loops to a single loop.

On Feb 1, 2011, at 1:34 PM, Andrew Trick wrote: > On Feb 1, 2011, at 1:08 PM, Andrew Clinton wrote: > >> I have a (non-entry) basic block that contains only PHI nodes and an >> unconditional branch (that does not branch to itself). Is it always >> possible to merge this block with it's successor and produce a >> semantically equivalent program? I'm