similar to: Bundling MachineInstr instructions before register allocation seems to always give errors

I am using machine instruction bundles [1] before register allocation. This appears not to be too common today and I'd really like some input on the intentions and plans of the current system. And would like some input on clean up proposals. [1] I am currently experimenting to use machine instruction bundles to reliably form macroop fusion opportunities without spills, reloads, splits or

> On Oct 27, 2016, at 5:05 PM, Andrew Trick <atrick at apple.com> wrote: > > >> On Oct 27, 2016, at 2:33 PM, Matthias Braun <mbraun at apple.com> wrote: >> >> == BUNDLE instruction / operands == >> For many backend passes a bundle can appear as a single unit. However one important tool >> here is having an iterator over all operands of this

Sergei, Thank you for your attention. My target is a custom VLIW DSP. I am not sure dependency dag is correct when it gets scheduled and packetized. Months ago, I submitted a bug at http://llvm.org/bugs/show_bug.cgi?id=17894 which explained more details. I am not sure my understanding of this bug is proper, but modified my local codes this way and it works for my target when scheduling and

Hello. I am using the post-RA (Register Allocation) scheduler to avoid data hazards by inserting other USEFUL instructions from the program (besides NOPs) and it breaks apart some sequences of instructions which should remain "glued" together. More exactly, in my [Target]ISelDAGToDAG.cpp it is possible that I replace for example a BUILD_VECTOR with a machine SDNode called

> On Oct 27, 2016, at 2:33 PM, Matthias Braun <mbraun at apple.com> wrote: > > == BUNDLE instruction / operands == > For many backend passes a bundle can appear as a single unit. However one important tool > here is having an iterator over all operands of this unit. > > The original RFC indicates that to achieve this without changing a big number > of passes an

On Thu, Mar 29, 2012 at 02:57:27PM -0500, Sergei Larin wrote: > Tom, > > I do not have your call stack, but packetizer calls > ScheduleDAGInstrs::buildSchedGraph to create dependency model. If this is > the first time you use the new MI sched infrastructure (like your target has > not implemented misched yet) there might be some work needed to implement > couple target

> On Oct 27, 2016, at 5:30 PM, Matthias Braun <mbraun at apple.com> wrote: > >> >> On Oct 27, 2016, at 5:05 PM, Andrew Trick <atrick at apple.com <mailto:atrick at apple.com>> wrote: >> >>> The system works because the default basic block iterator moves from bundle to >>> bundle skipping the instructions inside the bundle. Iterating

On Mar 29, 2012, at 1:18 PM, Tom Stellard <thomas.stellard at amd.com> wrote: > On Thu, Mar 29, 2012 at 02:57:27PM -0500, Sergei Larin wrote: >> Tom, >> >> I do not have your call stack, but packetizer calls >> ScheduleDAGInstrs::buildSchedGraph to create dependency model. If this is >> the first time you use the new MI sched infrastructure (like your

Hello. Because I experience optimizations (DCE, OoO schedule) which mess the correct semantics of the list of instructions lowered in ISelLowering from the VSELECT LLVM instruction, and these bad transformations happen even before scheduling, at later I-sel subpasses, I try to fix this problem by lowering VSELECT to only one pseudo-instruction and LATER translate it to a list of

Hi Evan, I just read your proposal and the following discussion for VLIW support and want to share my experience of writing a VLIW back-end for LLVM. I would not integrate the packetizer into the register allocator super class since it would reduce the flexibility for the back-end developer to add some optimization passes after the packetizer. Instead, I would add the packetizer as a separate

On Thu, Mar 29, 2012 at 03:51:10PM -0700, Andrew Trick wrote: > > On Mar 29, 2012, at 1:18 PM, Tom Stellard <thomas.stellard at amd.com> wrote: > > > On Thu, Mar 29, 2012 at 02:57:27PM -0500, Sergei Larin wrote: > >> Tom, > >> > >> I do not have your call stack, but packetizer calls > >> ScheduleDAGInstrs::buildSchedGraph to create

Machine Instruction Bundle in LLVM Hi all, There have been quite a bit of discussions about adding machine instruction bundle to support VLIW targets. I have been pondering what the right representation should be and what kind of impact it might have on the LLVM code generator. I believe I have a fairly good plan now and would like to share with the LLVM community. Design Criteria 1. The

Jakob, > The intention was to identify code that may have been converted from > the old style a little too quickly. I wanted to avoid bugs from a > global s/setIsInsideBundle/bundleWithPred/g search and replace. This is a good intent. Maybe a bit temporal but sound nevertheless. > finalizeBundle is calling 'MIBundleBuilder Bundle(MBB, FirstMI, > LastMI)' which ought to

On Oct 24, 2011, at 2:38 PM, Carlos Sánchez de La Lama wrote: > Hi Evan (and all), > >> I think any implementation that makes a "bundle" a different entity from MachineInstr is going to be difficult to use. All of the current backend passes will have to taught to know about bundles. > > The approach in the patch I sent (and I believe Timo's code works similar,

On Feb 1, 2013, at 3:43 PM, "Sergei Larin" <slarin at codeaurora.org> wrote: > I have a question about the following (four) asserts recently added in > bundleWithPred() and bundleWithSucc() (see below). What is the real danger > of reasserting a connection even if it already exist? The intention was to identify code that may have been converted from the old style a

On Oct 25, 2011, at 1:59 AM, Stripf, Timo wrote: > Hi all, > >> Ok, so in your proposal a bundle is just a special MachineInstr? That sounds good. How are the MachineInstr's embedded inside a bundle? How are the cumulative operands, implicit register defs and uses represented? > > I attached the packing and unpacking pass I used within my backend. In my solution multiple

Jakob, I have a question about the following (four) asserts recently added in bundleWithPred() and bundleWithSucc() (see below). What is the real danger of reasserting a connection even if it already exist? My problem with them happens when I try to call finalizeBundle() on an existing bundle to which I have added a new instruction. The goal - a new bundle header with liveness abbreviation, but

On Feb 4, 2013, at 8:59 AM, "Sergei Larin" <slarin at codeaurora.org> wrote: > Jakob, > >> The intention was to identify code that may have been converted from >> the old style a little too quickly. I wanted to avoid bugs from a >> global s/setIsInsideBundle/bundleWithPred/g search and replace. > > This is a good intent. Maybe a bit temporal but

Hi all, > Ok, so in your proposal a bundle is just a special MachineInstr? That sounds good. How are the MachineInstr's embedded inside a bundle? How are the cumulative operands, implicit register defs and uses represented? I attached the packing and unpacking pass I used within my backend. In my solution multiple MachineInstruction are packed into one variadic "PACK"

Evan, What would change if tomorrow we got a VLIW target/back end with some certain properties - let's say no intra-packed deps - would it sway your opinion in either direction? Would it be a natural prerogative to implement it certain way for such hypothetical contributor/submitter? Thanks. Sergei Larin -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu