similar to: RFC: Introducing CfgTraits and type-erased CfgInterface / CfgBlockRef / CfgValueRef

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

On Tue, Nov 27, 2012 at 12:37 AM, Tom Stellard <tom at stellard.net> wrote: > Assuming I caught all the coding style mistakes you pointed out, what > else needs to be done to be able to commit this code? Hello Tom, There are still a few classes of coding style issues... + /// CreateLiveInRegister - Helper function that adds Reg to the LiveIn list + /// of the DAG's

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

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

Hi, As part of an ongoing work to extend the GraphDiff (this models a CFG view), I came across the need to have a common interface for accessing successors/predecessors in various IR units, such that a type such as `typename NodeT::succ_iterator` could be used in templated code. In particular, the need arose for BasicBlocks, MachineBasicBlocks, VPBlockBase and clang::CFGBlock. The least invasive

> On May 26, 2015, at 1:37 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> >> On 2015-May-26, at 09:46, Alex L <arphaman at gmail.com> wrote: >> >> Hi all, >> >> The CodeGen library is a big bag of interdependent bits. This caused >> a circular dependency in the MIR serialization commit (r237954), which got >>

On Thu, Nov 29, 2012 at 06:28:15PM +0200, Dmitri Gribenko wrote: > On Tue, Nov 27, 2012 at 12:37 AM, Tom Stellard <tom at stellard.net> wrote: > > Assuming I caught all the coding style mistakes you pointed out, what > > else needs to be done to be able to commit this code? > > Hello Tom, > > There are still a few classes of coding style issues... > > +

Andrew Kaylor wrote: >In general, the current "strict FP" handling stops at instruction >selection. At the MachineIR level we don't currently have a mechanism >to prevent inappropriate optimizations based on floating point >constraints, or indeed to convey such constraints to the backend. >Implicit register use modeling may provide some restriction on some

Dear LLVM developers, My goal is to write LLVM Machine IR (MIR) passes to analyze the assembly source code. But it seems I need to find a way to translate the handwritten assembly code into MIR format first. Is there any materials, or any modules in LLVM source code, that can help to translate assembly code into LLVM MIR for analysis? Or is there any easier ways to analyze assembly code in MIR

On Sat, Nov 17, 2012 at 10:56:26PM +0100, Benjamin Kramer wrote: > > On 01.11.2012, at 14:44, Tom Stellard <tom at stellard.net> wrote: > > > Moving this thread to llvmdev. > > > > On Tue, Oct 30, 2012 at 11:09:34PM -0700, Chris Lattner wrote: > >> On Oct 30, 2012, at 11:35 AM, Tom Stellard <tom at stellard.net> wrote: > >>>> Hi

Llvm-mctoll will raise a binary back to LLVM IR. Not exactly what you want but it might be something you can leverage. https://github.com/microsoft/llvm-mctoll On Mon, Nov 25, 2019 at 1:19 PM Nicolai Hähnle via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Nov 21, 2019 at 3:37 AM Lele Ma via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > My goal is to write

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 Jan 9, 2018, at 1:53 PM, Kaylor, Andrew via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > I think we’re going to need to create a new mechanism to communicate strict FP modes to the backend. I think we need to avoid doing anything that will require re-inventing or duplicating all of the pattern matching that goes on in instruction selection (which is the reason we’re

Hi All, A self-follow up and rephrase of my previous question with updated subject: What I want to do is to analyze hand-written assembly code with 'full details' where semantics of each instruction can be known in LLVM passes. Many of such instructions have no corresponding counterparts in IR/MIR forms, such as 'syscall' 'iret', etc. At MC level, such assembly code can

+1. Could those two be subdirectories of one “Machine-Related-Stuff” directory? E.g., MachineStuff/IR MachineStuff/CodeGen Where MachineStuff is something meaningful :). That way, they keep a logic bound, more formal than the naming convention. My 2c. Q. > On May 26, 2015, at 9:28 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 26, 2015, at 1:46 PM, Owen Anderson

Hello all, Is there an easy way to get the human-readable opcode mnemonic (e.g., "MOV32ri64", "CMP32ri8", "JLE_1") for a MachineInstr? I am writing a backend analysis pass for security research, where the idea is for a researcher to examine the output of my pass and identify instructions from it for use in an attack. Right now I'm representing unique

On Tue, Jan 09, 2018 at 06:53:51PM +0000, Kaylor, Andrew via cfe-dev wrote: > I think we're going to need to create a new mechanism to communicate > strict FP modes to the backend. I think we need to avoid doing anything > that will require re-inventing or duplicating all of the pattern > matching that goes on in instruction selection (which is the reason >

2017-07-24 16:14 GMT-07:00 Quentin Colombet via llvm-dev < llvm-dev at lists.llvm.org>: > Hi River, > > On Jul 24, 2017, at 2:36 PM, River Riddle <riddleriver at gmail.com> wrote: > > Hi Quentin, > I appreciate the feedback. When I reference the cost of Target Hooks it's > mainly for maintainability and cost on a target author. We want to keep the >

>The standard argument against trying to introduce "scope-like" mechanisms to LLVM IR is inlining; >unless you're going to prevent functions that use stricter/laxer FP rules from being inlined >into >each other (which sounds disastrous), you're going to need to communicate strictness on an >instruction-by-instruction basis. If the backend wants to handle that by