search for: finalizebundles

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

...ld be eliminated, but it's a bootstrapping mechanism that we rely on for now during postRA passes only. VLIWPacketizer calls finalizeBundle explicitly because it's running after regalloc. We do not want to see any Bundle instructions prior to regalloc. So a preRA scheduler should not call finalizeBundles. It can create bundles simply by setting the isInsideBundle flag on MachineInstrs. If you allow internal register dependencies you would also need to set isInternalRead on those MachineOperands. -Andy

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

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

...t it's a bootstrapping mechanism that we rely on for now during postRA passes only. > > VLIWPacketizer calls finalizeBundle explicitly because it's running after regalloc. > > We do not want to see any Bundle instructions prior to regalloc. So a preRA scheduler should not call finalizeBundles. It can create bundles simply by setting the isInsideBundle flag on MachineInstrs. If you allow internal register dependencies you would also need to set isInternalRead on those MachineOperands. > Thanks, this information is really helpful. One question, though: If preRA bundles can't have...

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

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

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 hooks. isSchedulingBoundary is one of them. Also try to disable that assert and see what happens. It

On Thu, Mar 29, 2012 at 01:50:58PM -0500, Sergei Larin wrote: > Tom, > > What is in your isSchedulingBoundary? If it contains isLabel you might > need to disable that assert: > > assert(!MI->isTerminator() && !MI->isLabel() && > "Cannot schedule terminators or labels!"); > > Sergei Larin > > -- > Qualcomm

Hello. I am having difficulties to bundle MachineInstr instructions, before register allocation (RA). More exactly, I registered a simple pass in addPreRegAlloc() that is trying to create bundles. I see that it is written at http://llvm.org/docs/CodeGenerator.html#machineinstr-bundles: <<Packing / bundling of MachineInstr’s should be done as part of the register

I'm trying to figure out how Hexagon (I'm using it as an example for my own VLIW) is handling bundles with 1 instruction, but I don't quite get it. Here is the code that I have for a endPacket // endPacket - End the current packet, bundle packet instructions and reset // DFA state. void VLIWPacketizerList::endPacket(MachineBasicBlock *MBB,

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

Jakob, >... In this case you should either erase the old BUNDLE first, or unbundle it > from the instructions you are trying to finalize. This is exactly my point - I have to unbundle everything to re-bundle it back in :) ...but this case is trivial and I am OK with it. What is more unclear to me is this. How do you use Bundle.insert(I, MI->removeFromBundle()) Where MI == Bundle.End?

On 10/27/2016 4:33 PM, Matthias Braun via llvm-dev wrote: > > In fact I am not sure why you would even wait with the finalization and do it > in a separate pass rather than doing it immediately after forming the bundle. > Using the pass today does not even work as the MachineVerifier will reject the > intermediate unfinalized state (missing internal read markers). I'd suggest to

Is there a way to place a bundle a BUNDLE instruction into a packet with one instruction? Current code to end packet doesn't handle this case: // endPacket - End the current packet, bundle packet instructions and reset // DFA state. void VLIWPacketizerList::endPacket(MachineBasicBlock *MBB, MachineInstr *MI) { if (CurrentPacketMIs.size() > 1) {

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

> 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 Oct 27, 2016, at 5:23 PM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 10/27/2016 4:33 PM, Matthias Braun via llvm-dev wrote: >> >> In fact I am not sure why you would even wait with the finalization and do it >> in a separate pass rather than doing it immediately after forming the bundle. >> Using the pass today does not