similar to: Metadata in LLVM back-end

Am 31/07/20 um 22:47 schrieb David Greene: @David > Thanks for keeping this going, Lorenzo. > > Lorenzo Casalino via llvm-dev <llvm-dev at lists.llvm.org> writes: > >>> The first questions need to be “what does it mean?”, “how does it >>> work?”, and “what is it useful for?”. It is hard to evaluate a >>> proposal without that. >> Hi everyone,

Le 04/11/20 à 17:40, David Greene a écrit : > Sorry about the late reply. > > Lorenzo Casalino <lorenzo.casalino93 at gmail.com> writes: > >>>>> - Should not impact compile time excessively (what is "excessive?") >>>> Probably, such estimation should be performed on >>> Did something get cut off here? >> Uops. Yep, I removed a

Am 07/08/20 um 22:54 schrieb David Greene: > Lorenzo Casalino via llvm-dev <llvm-dev at lists.llvm.org> writes: > >>> As with IR-level metadata, there should be no guarantee that metadata is >>> preserved and that it's a best-effort thing. In other words, relying on >>> metadata for correctness is probably not the thing to do. >> Ok, I made a

Am 31/08/20 um 14:10 schrieb David Greene: > Lorenzo Casalino via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> Furthermore, after register allocation there is a non-negligible effort >> to properly annotate instructions which share the same output register... >> >> Concerning the usage of the live ranges to tie annotated instruction and >> intrinsic,

Am 08/09/20 um 17:57 schrieb David Greene: > Lorenzo Casalino <lorenzo.casalino93 at gmail.com> writes: > >> Am 31/08/20 um 14:10 schrieb David Greene: >>> Lorenzo Casalino via llvm-dev <llvm-dev at lists.llvm.org> writes: >>> >>>> Furthermore, after register allocation there is a non-negligible effort >>>> to properly annotate

Am 19/08/20 um 22:37 schrieb David Greene: > Lorenzo Casalino via llvm-dev <llvm-dev at lists.llvm.org> writes: > >>>> I was imagining a per-instruction data-structure collecting metadata info >>>> related to that specific instruction, instead of having several metadata info >>>> directly embedded in each instruction. >>> Interesting. At

Hi debuginfo cabal, tl;dr: I'd like to know what people think about an alternative to DBG_VALUE instructions describing variable locations in registers, virtual or real. Before instruction selection in LLVM-IR we identify the _values_ of variables [0] by the instruction that computes the value; I believe we should be able to do the same post-isel, and it would avoid having to analyse register

Dear All, I am performing some analysis on a traditional IR Module Pass in LLVM, with that analysis I want to tag the places I will need to extract file offsets from as custom symbols. Ideally I would want to attach some metadata to a IR instruction, and have it be accessible when I perform a backend MF pass. Essentially I want to pass the information I collected and generated in the IR pass,

Hi to everyone, while working with the machine scheduler for a personal project, I came up with the necessity of inserting a backup boundary in the MachineSchedulerStrategy -- specifically, the PostGenericScheduler -- to hold a copy the scheduler's state, in order to implement a really trivial (and really inefficient) backtracking mechanism. This approach leads to a subtle "segmentation

> opt -load lib­dum­my­pass.so -dum­my­pass hel­lo.ll Looks like you are loading a shared library different from "LLVMHello.so". did you change the name of the compilation unit from "Hello.cpp" into "dummypass.cpp"? (As asked previously by Andrzej) did you register the dummy pass? > RegisterPass<DummyPass> X("dummypass",

On Oct 5, 2012, at 12:08 AM, Nick Lewycky <nicholas at mxc.ca> wrote: > I absolutely think that we should have something like TargetData (now DataLayout) but for the vector types and operations. However, I'm not familiar with "Target Lowering Interface". Could you explain? I agree. Once we make the codegen accessible to the IR-level passes we need to start talking about

Hi, Thank you all for keeping this going. Indeed I was not aware that the discussion was going on, I am really sorry for this late reply. I understand Chris' point about metadata design. Either the metadata becomes stale or removed (if we do not teach transformations to preserve it), or we end up modifying many (if not all) transformations to keep the data intact. Currently in the IR, I feel

Thanks David! > On Nov 9, 2018, at 08:36, David Greene <dag at cray.com> wrote: > > Daniel Sanders via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> I've been working on the GlobalISel combiner recently and I'd like to >> share the plan for how Combine Rules will be defined in GlobalISel and >> solicit feedback on it. > > This is

Hi all, Currently metadata (other than debug info) can be attached to IR instructions but disappears during DAG selection. My question is why we do not keep the metadata during code lowering and then attach to MachineInstr, just as for IR instructions? Is there any technical challenge, or is it only because nobody wants to do so? Thanks for your help, Best, -------------- next part

Hi everyone, This RFC concerns the design and architecture of a generic machine instruction combiner/optimizer framework to be developed as part of the GISel pipeline. As we transition from correctness and reducing the fallback rate to SelectionDAG at -O0, we’re now starting to think about using GlobalISel with optimizations enabled. There are obviously many parts to this story as optimizations

Thanks for the suggestions Vedant. Synthetic debug info is an interesting idea that sounds worthwhile. Could this be implemented as a “wrapper” pass that automatically decorates debug info before and after a specific pass run in opt (or pipeline of passes)? It might be useful to be able to easily enable this for a wide range of tests without having to manually modify each run line, perhaps as an

Hi, [+ Quentin] Sorry for the late reply. > On Feb 13, 2019, at 9:09 AM, Nikola Prica <nikola.prica at rt-rk.com> wrote: > > On 12.02.2019. 18:06, Adrian Prantl wrote: >> [+ some folks more knowledgable about the Machine layer than me.] >> > That would be useful for us too! :) > > >>> On Feb 12, 2019, at 5:07 AM, Nikola Prica <nikola.prica at

Hi all, As much as possible I would rather we avoid any kind of metadata in MIR to express the semantic of instructions. Instead I would prefer that each back provides a way to interpret what an instruction is doing. What I have in mind is something that would generalize what we do in the peephole optimizer for instance (look for isRegSequenceLike/getRegSequenceInputs and co.) or what we have for

On Mon, 01 Oct 2012 21:26:54 -0700 Chris Lattner <clattner at apple.com> wrote: > > On Oct 1, 2012, at 6:16 PM, greened at obbligato.org wrote: > > > Sanjoy Das <sanjoy at playingwithpointers.com> writes: > > > >> In short, I propose a intrinsic based approach which hinges on the > >> concept of a "parallel map". The immediate

Currently there is a series of patches undergoing review[0] that seek to enable the use of multiple IR/MIR values when describing a source variable's location. The current plan for the MIR is to add a new instruction, DBG_VALUE_LIST, that supports this functionality by having a variable number of operands. It may be better however to simply replace the existing DBG_VALUE behaviour entirely