similar to: RFC: Making a common successor/predecessor interface

Hi Dave, It may be possible to do this with the current API, but what I was looking for is a common API for existing block types. For example there is no succ_begin for Machine BasicBlock. I'm looking to make the CFGSuccessors and CFGPredecessors classes in CFGDiff.h templated, and this needs a common API for all types instantiations. Does this clarify your question or did I misunderstand

On Tue, Mar 10, 2020 at 2:30 PM David Blaikie <dblaikie at gmail.com> wrote: > > > On Tue, Mar 10, 2020 at 8:31 AM Alina Sbirlea <alina.sbirlea at gmail.com> > wrote: > >> Hi Dave, >> >> It may be possible to do this with the current API, but what I was >> looking for is a common API for existing block types. For example there is >> no

Hi Jakub, On Tue, Jul 7, 2020 at 6:25 AM Jakub (Kuba) Kuderski <kubakuderski at gmail.com> wrote: > There's a lot of heavily templated code in generic DomTee construction/updater, MemSSA updater, and GraphDiff that has become really hard to modify. For the context, Alina (cc'd) was recently looking into making the domtree code work with 'CFG views'; the basic idea is to

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 >>

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 all, This is a request for comment on a series of patches which introduce a new way of writing algorithms that are generic over different types of CFG. What is this? ============= This series of patches introduces a set of classes and templates for: 1. Working on basic blocks and values generically, in particular with the same algorithm implementation on both LLVM IR and MachineIR (in SSA

Hi, this is a bit of a newbie question: I am trying to discover, given a block with a conditional and its successors, which condition (T/F) each successor applies to. There's almost identical code in CFGPrinter.cpp, but where it gets called in GraphWriter.h, the child_iterator type is a pretty hairy thing, so I still don't quite understand how to get one from a BasicBlock in my own

On Tue, 4 Jul 2006, Fernando Magno Quintao Pereira wrote: > However, it does not remove all the critical edges. I am getting a very > weird dataflow graph (even without the Break Critical edges pass). The > dataflow generated by MachineFunction::dump() for the program below is > given here: > http://compilers.cs.ucla.edu/fernando/projects/soc/images/loop_no_crit2.pdf ... > The

> On 25 May 2018, at 01:46, Aaron via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > LLVM optimization pass gives an error "Terminator found in the middle of a basic block!" since basic block IR may have multiple "ret" instructions. It seems LLVM does not accept multiple return in a basic block by default. > Yes, if you’re inserting

Hi all, LLVM optimization pass gives an error "Terminator found in the middle of a basic block!" since basic block IR may have multiple "ret" instructions. It seems LLVM does not accept multiple return in a basic block by default. Is there a specific optimization or pass that I can enable to remove unreachable codes in basic blocks? Best, Aaron -------------- next part

Hi all, I've been investigating a machine verifier failure on the attached testcase, and I'm tempted to say the verifier is wrong and should accept it. Skip the description for the proposed change. On AArch64, the verifier complains with: *** Bad machine code: MBB exits via unconditional branch but doesn't have exactly one CFG successor! *** - function: t4 - basic

Hi! As the title suggests, I'd like to generalize llvm::IDFCalculator to be able to calculate control dependencies on clang's CFG. The issue is however, that many data structures it uses are "hardcoded" to use llvm::BasicBlock, and requires a lot of code to turn it into template arguments. I managed to pull this off by hammering the code until it compiled, and it works

On Mon, May 14, 2012 at 4:39 PM, John Criswell <criswell at illinois.edu>wrote: > On 5/14/12 4:32 AM, Umesh Kalappa wrote: > > Hi All , > > Was trying to build the LLVM src from > http://llvm.org/svn/llvm-project/llvm/branches/release_30 ,But unable to > build the same and clang poped up with below error . > > > First, it sounds like you're building LLVM

Hi All , Was trying to build the LLVM src from http://llvm.org/svn/llvm-project/llvm/branches/release_30 ,But unable to build the same and clang poped up with below error . llvm[1]: Compiling IntervalMap.cpp for Debug build In file included from /root/projects/safecode/llvm/lib/Support/IntervalMap.cpp:14: /root/projects/safecode/llvm/include/llvm/ADT/IntervalMap.h:1980:32: error: use

Hi all, After a long ride, I'm planning to turn on the use of MemorySSA for loop passes (D58311 <https://reviews.llvm.org/D58311>) tomorrow (8/29). Please let me know if you have issues, concerns or feedback on this. Best, Alina -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 5/14/12 4:32 AM, Umesh Kalappa wrote: > Hi All , > > Was trying to build the LLVM src from > http://llvm.org/svn/llvm-project/llvm/branches/release_30 ,But unable > to build the same and clang poped up with below error . First, it sounds like you're building LLVM 3.0, Poolalloc, and SAFECode with an unmodified version of clang. Is this correct? If so, which version of

Hi all, as proposed in http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/020396.html I implemented the algorithm presented in [Ball94]. It only instruments the minimal number of edges necessary for edge profiling. The main changes introduced by this patch are: *) a interface compatible rewrite of ProfileInfo *) a cleanup of ProfileInfoLoader (some functionality in ProfileInfoLoader

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,

As stated in an earlier email, I am working on getting break/continue to work correctly for my backend, but I ran into another issue with codegen and the CFG. It seems that code gen is not done based on the CFG, but rather on the block numbers, and the function call MachineFunction::RenumberBlocks doesn't renumber the blocks based on the CFG. So how can I modify the CFG so that when codegen

Hi, I'd like to understand if it makes sense to keep BasicAA as a not CFG-only pass, or if it can be updated to CFG-only. The change was made in D44564 <https://reviews.llvm.org/D44564>. >From what I gathered the motivation was PhiValuesAnalysis not being properly updated, and BasicAA having an instance of it. PhiValuesAnalysis now uses callback values to invalidate deleted values (