search for: mibundlebuild

...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 work with pre-bundled instructions. Not exactly. Let me illustrate couple cases here (for illustration purposes "^" means "isBundledWithPred()" and "v" means "isBundledWithSucc()"): I have the followi...

...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 work with pre-bundled instructions. > > Not exactly. Let me illustrate couple cases here (for illustration purposes > "^" means "isBundledWithPred()" and "v" means "isBundledWithSucc()"):...

...t; >> 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 work with pre-bundled instructions. > > > > Not exactly. Let me illustrate couple cases here (for illustration > > purposes "^" means "isBundledWithPred()" and "v" means > "isBu...

...izeBundle() on an existing bundle to which I > have added a new instruction. The goal - a new bundle header with liveness > abbreviation, but because of these asserts I now have to unbundle all, and > re-bundle them right back again for no obvious benefit... finalizeBundle is calling 'MIBundleBuilder Bundle(MBB, FirstMI, LastMI)' which ought to work with pre-bundled instructions. FirstMI and LastMI must be pointing at bundle boundaries, but you shouldn't need to unbundle everything. Which iterators are you passing to finalizeBundle? /jakob

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

...nsert(I, MI->removeFromBundle()) > > Where MI == Bundle.End? > > This happens if I want to add unbundled instruction to a bundle that > immediately precedes it in the same BB. The moment you remove MI from BB > iterators will not work properly. Yes, that is a problem because MIBundleBuilder keeps an End iterator. What do you think, should we add a Bundle.moveIntoBundle() function? /jakob

...s > broken up immediately before (or during!) MC emission. > > > > -Owen > I just tried this but something is wrong here. Well, I have not used bundles at > all. > I just know how they work conceptually. This compiled okay but I got some > constraint errors. > > MIBundleBuilder(MBB, I) > .append(BuildMI(MF, DL, TII.get(Mips::LiRxImmAlignX16), V0) > .addExternalSymbol("_gp_disp", MipsII::MO_ABS_HI)) > .append(BuildMI(MF, DL, TII.get(Mips::AddiuRxPcImmX16), V1) > .addExternalSymbol("_gp_disp", MipsII::MO_ABS_LO))...

...other is to use a pseudo instruction that is broken up immediately before (or during!) MC emission. > > —Owen I just tried this but something is wrong here. Well, I have not used bundles at all. I just know how they work conceptually. This compiled okay but I got some constraint errors. MIBundleBuilder(MBB, I) .append(BuildMI(MF, DL, TII.get(Mips::LiRxImmAlignX16), V0) .addExternalSymbol("_gp_disp", MipsII::MO_ABS_HI)) .append(BuildMI(MF, DL, TII.get(Mips::AddiuRxPcImmX16), V1) .addExternalSymbol("_gp_disp", MipsII::MO_ABS_LO));

...immediately before (or during!) MC emission. >>> -Owen >> I just tried this but something is wrong here. Well, I have not used bundles at >> all. >> I just know how they work conceptually. This compiled okay but I got some >> constraint errors. >> >> MIBundleBuilder(MBB, I) >> .append(BuildMI(MF, DL, TII.get(Mips::LiRxImmAlignX16), V0) >> .addExternalSymbol("_gp_disp", MipsII::MO_ABS_HI)) >> .append(BuildMI(MF, DL, TII.get(Mips::AddiuRxPcImmX16), V1) >> .addExternalSymbol("_gp_disp",...

+the list again On Sep 17, 2013, at 3:48 PM, reed kotler <rkotler at mips.com> wrote: > On 09/17/2013 03:46 PM, Owen Anderson wrote: >> On Sep 17, 2013, at 3:08 PM, reed kotler <rkotler at mips.com> wrote: >> >>> Is there any way, except for using bundles, to force two instructions to be sequentially executed? >> What level of codegen are you working at?

...immediately before (or during!) MC emission. >>> -Owen >> I just tried this but something is wrong here. Well, I have not used bundles at >> all. >> I just know how they work conceptually. This compiled okay but I got some >> constraint errors. >> >> MIBundleBuilder(MBB, I) >> .append(BuildMI(MF, DL, TII.get(Mips::LiRxImmAlignX16), V0) >> .addExternalSymbol("_gp_disp", MipsII::MO_ABS_HI)) >> .append(BuildMI(MF, DL, TII.get(Mips::AddiuRxPcImmX16), V1) >> .addExternalSymbol("_gp_disp",...

...g!) MC emission. >>>> -Owen >>> I just tried this but something is wrong here. Well, I have not used bundles at >>> all. >>> I just know how they work conceptually. This compiled okay but I got some >>> constraint errors. >>> >>> MIBundleBuilder(MBB, I) >>> .append(BuildMI(MF, DL, TII.get(Mips::LiRxImmAlignX16), V0) >>> .addExternalSymbol("_gp_disp", MipsII::MO_ABS_HI)) >>> .append(BuildMI(MF, DL, TII.get(Mips::AddiuRxPcImmX16), V1) >>> .addExternalSymbol("_gp...

I think this after a second. I got your point. I can define a pseudo instruction for an instr-pair and expand it after post-RA-sched. as you said, in preEmitPass. The original intrinsic can also be kept. I just convert the intrinsic to pseudo instruction in TargetLower. Thank you for your enlightening suggestion! thanks, --lx On Sat, Nov 23, 2013 at 8:37 PM, Amara Emerson <amara.emerson at

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

...t; > > > Where MI == Bundle.End? > > > > This happens if I want to add unbundled instruction to a bundle that > > immediately precedes it in the same BB. The moment you remove MI from > > BB iterators will not work properly. > > Yes, that is a problem because MIBundleBuilder keeps an End iterator. > > What do you think, should we add a Bundle.moveIntoBundle() function? > > /jakob

Hi, Thanks for your explanations! How is the big picture for supporting in-order VLIW architectures and the like though? I am asking because I am currently implementing instruction scheduling in our own backend for our custom Patmos processor, for which I need to support both branch delay slots and bundles, some restrictions regarding bundles. For the moment, I am quite happy with a simple