similar to: [LLVMdev] MachineInstr and Machine/BasicBlock Metadata

On May 7, 2012, at 7:21 AM, Ralf Karrenberg <Chareos at gmx.de> wrote: > Hi Duncan, > > On 5/6/12 6:12 PM, Duncan Sands wrote: >> Hi Ralf, >> >>> Is there a clean way to attach metadata nodes to Arguments and/or >>> BasicBlocks? >> >> not at the moment. Feel free to work on adding this functionality! > > I am looking into that

Hi Duncan, On 5/6/12 6:12 PM, Duncan Sands wrote: > Hi Ralf, > >> Is there a clean way to attach metadata nodes to Arguments and/or >> BasicBlocks? > > not at the moment. Feel free to work on adding this functionality! I am looking into that now. I decided to temporarily go for the following syntax for BasicBlock metadata (subject to discussion): entry:

Hi Ankur, For a MachineBasicBlock you can call getBasicBlock() to find the IR level BasicBlock from which it was generated (if there isn't a one, it will return NULL). I don't know of a way to get a finer granularity than that, though. -Jim On Jul 1, 2011, at 1:06 AM, ankur deshwal wrote: > Hi, > > Is there any way to get a pointer to the LLVM Instr from which a >

On 10/23/2012 1:58 PM, John Criswell wrote: > Dear All, > > I'm enhancing a MachineFunctionPass that enforces control-flow > integrity. One of the things I want to do is to set the alignment of > an instruction (by adding NOPs before it in the MachineBasicBlock or > by emitting an alignment directive to the assembler) if it causes a > specific sequence of bytes to be

Hi everybody, Is there a clean way to attach metadata nodes to Arguments and/or BasicBlocks? It looks to me like one can directly attach metadata only to instructions. My current workaround is to insert a call to a dummy function that holds metadata for its parent block - pretty ugly, but manageable. The same problem arises when I want to store specific information about the arguments of a

So, is there any chance that metadata for basic blocks is considered a useful feature? There is a patch ready and on the commits-list, it compiles, passes all tests, has a test case of its own, and (as far as I can tell) does not interfere with anything. Cheers, Ralf On 5/7/12 4:21 PM, Ralf Karrenberg wrote: > Hi Duncan, > > On 5/6/12 6:12 PM, Duncan Sands wrote: >> Hi Ralf,

Hi Ralf, > Is there a clean way to attach metadata nodes to Arguments and/or > BasicBlocks? not at the moment. Feel free to work on adding this functionality! > It looks to me like one can directly attach metadata only to instructions. > My current workaround is to insert a call to a dummy function that holds > metadata for its parent block - pretty ugly, but manageable. The

Indeed, Nadav. I also want to store information about loops as block-metadata of the loop header, but as you say this is easily doable by using block terminators. However, for the divergence analysis, we cannot use the terminators, because the properties of a block are determined by multiple criterions. If you do not want to introduce ugly dummy-calls to store that data (and write even more

On Oct 23, 2012, at 6:22 PM, Joshua Cranmer <pidgeot18 at gmail.com> wrote: > On 10/23/2012 1:58 PM, John Criswell wrote: >> Dear All, >> >> I'm enhancing a MachineFunctionPass that enforces control-flow integrity. One of the things I want to do is to set the alignment of an instruction (by adding NOPs before it in the MachineBasicBlock or by emitting an alignment

On 07/05/12 22:58, Dan Gohman wrote: > What kind of things might basic block metadata be used for? > > Dan I'd be really keen for this to go in. In order to support worse case execution time analysis on compiled binaries we (XMOS) need a way to mark paths that should be excluded when checking timing constraints. A typical query is "Check the worse case execution time from A to

If we were to implement the #unroll pragma, we would want to add metadata to loop headers. But, it's not a big deal since we can simply add this metadata to block terminators. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Dan Gohman Sent: Tuesday, May 08, 2012 00:58 To: Ralf Karrenberg Cc: llvmdev at cs.uiuc.edu List

Hi Dan, I am using it to store results of a vectorization analysis. A BasicBlock has certain properties in this context, e.g. we mark control flow that may never diverge in different instances ("threads" if you think in terms of CUDA) of the same function by marking the corresponding blocks. This information is later used when linearizing the function (control flow to data flow

Hello group, Per my posting on the Clang Newsgroup. I'm interested in doing some loop optimizations, towards this end I would like to add some custom Metadata to a Loop header. Loops in LLVM are represented using BasicBlocks, but unfortunately you can NOT add MetaData to a BasicBlock. Although you can add Metadata to an instruction. So I'm proposing to add the Metadata manipulation

Hi, Recently, I am working on some information collection on the machine instruction (MachineInstr) level. But, sometimes, I need check the corresponding IR level instruction of the a machine instruction. When visiting a machine instruction which is a call (MachineInstr::isCall()), I need to check the arguments of this call site. I know that the CallSite class provides good facility for this

Hello, I was looking at how the memory for MachineBasicBlocks is managed and something seems strange. On one hand, a MachineFunction uses a recycling allocator to create and destroy MBBs without costly heap allocation (the same is done for MachineInstrs, MachineOperands, etc.). On the other hand, each MBB also has a number of STL vectors within it. For example, for Predecessors, Successors,

Hi all, I am attempting to implement the "reaching definitions" data-flow algorithm on (X86) MachineBasicBlocks for an analysis pass. To do this, I need to compute gen/kill sets for machine basic blocks. To start with, I am only considering the general-purpose registers, RAX-R15 and their sub-registers. Thus, I need to examine each MachineInstr to determine which register(s) it

A question about how the memory of object in LLVM are managed. I dived in some source files but still don't have any idea how the memory of MachineInstr object are managed. It doesn't look like reference counting. I'm writing an instruction scheudling code, the new order of MachineInstr* in a MachineBasicBlock is stored in a "schedule". All MachineInstr* in

Hi, I'm still having problems implementing my custom inserter in the X86 backend. I found a solution to my last problem (http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-October/078296.html), by using a virtual register. The binary works when it's compiled in -O0, but not in -O1,-O2,... I really can't figure what I'm doing wrong... Any idea? Here is the code of my custom

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