similar to: [LLVMdev] Comments on the bundle proposal

Hi, On 12/07/2011 01:10 AM, Krzysztof Parzyszek wrote: > Another approach would be to have a pseudo-instruction (say, "macro"), > which would be associated with a sequence of instructions, which have > been outlined, and which have been replaced by the "macro" instruction. > The "macro" instruction would have the information about registers used > and

On Dec 6, 2011, at 3:10 PM, Krzysztof Parzyszek wrote: > - How about having bundles that contain branch targets (other than the > first instruction) from the outside of the bundle? This seems like something > that has a potential for causing trouble, but I can't think of any specific > scenario at the moment. I think bundles could cross branches with some care. But I don't

On Wed, Dec 07, 2011 at 10:14:22AM -0800, Andrew Trick wrote: > > On Dec 6, 2011, at 3:10 PM, Krzysztof Parzyszek wrote: > > > - How about having bundles that contain branch targets (other than the > > first instruction) from the outside of the bundle? This seems like something > > that has a potential for causing trouble, but I can't think of any specific >

> No. Bundles with single instructions are not allowed, but bundles can be > mixed with instructions that are not bundled. > > -Krzysztof > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by The Linux Foundation > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org >

. and yes, one more thing. On some architectures it might be desirable to know the _order_ of instructions in the packet. That is a bit trickier.. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Friday, December 02, 2011 2:40 PM To: LLVM Dev Subject: [LLVMdev]

On Dec 2, 2011, at 2:41 PM, Sergei Larin wrote: > … and yes, one more thing. On some architectures it might be desirable to know the _order_ of instructions in the packet. That is a bit trickier…. Isn't that just the order of the instructions in the list? I don't see anything that prevents getting the order of instructions. It might require iterator over MIs in the packet. But for

Evan, I will need to comprehend it better, but one small comment right away. Did we not discuss one more option for bundle implementation - global cycle ID. We would add an unsigned int field to MI definition representing "global scheduling cycle". All MIs with the same global cycle value belong to one group/packet. Zero means unscheduled MI. That is light weight,

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

Hi paulr, Thank you for your response :) Hi Krzysztof, This is really helpful! Thank you for your guidance!! I would like to trace the Hexagon's llvm implementation. I am very interested on how Hexagon implement instruction pattern matching, instruction scheduling, and register allocation, could you give me some suggestions or reading lists to help me understand Hexagon's llvm

> No. An instruction on its own is equivalent to a bundle with that > instruction only. Also, a BUNDLE must have at least 2 instructions. > > -Krzysztof > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by The Linux Foundation > _______________________________________________ > LLVM Developers mailing list > llvm-dev at

> On Jun 27, 2017, at 2:10 PM, Matthias Braun <mbraun at apple.com> wrote: > >> >> On Jun 27, 2017, at 4:55 AM, Mikael Holmén via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi Quentin and llvm-dev, >> >> I've got a regalloc-related question that you might have an opinion or answer about. >> >> In our out-of-tree

You can have > > BUNDLE // 2 instructions in a bundle > instruction1 // > instruction2 // > instruction3 // single, non-bundled instruction > BUNDLE // another bundle with 2 instructions > instruction4 // > instruction5 // > > instruction3 is not bundled with anything, and it's between two other > bundles---that's what I

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

> On Jun 27, 2017, at 2:44 PM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 6/27/2017 4:35 PM, Quentin Colombet via llvm-dev wrote: >> Yeah I was reading this as “only the non-touched part are dead”, and that’s what I’d like to see in the representation longer. Obviously, the register is not dead as a whole here :) > > I think that having

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

On 11/1/2016 4:28 PM, Martin J. O'Riordan via llvm-dev wrote: > I do not even pretend to know much about Dwarf and the representation of debug information, but it does appear that there is little or no support for the idea that a single "instruction" can correspond to multiple diverse lines in the source file. There is. There is even a patch for LLVM:

Hi, > Has anyone attempted the port of LLVM to a VLIW architecture? Is there > any publication about it? I have developed a derivation of MachineInstr class, called MachineInstrBundle, which is essnetially a VLIW-style machine instruction which can store any MI on each "slot". After the scheduling phase has grouped MIs in bundles, it has to call MIB->pack() method, which

> On Jun 28, 2017, at 5:10 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Oh wait, vreg1 is indeed used. > Yeah, having a dead flag here sounds wrong. I mean on the instruction itself. On the bundle, that’s debatable. That would fit the semantic “if no side effect you can kill it” (here there is side effect, we define other vregs). > >> On

Hi all, here is the current (unfinished) version of the VLIW support I mentioned. It is a patch over svn rev 141176. It includes the MachineInstrBundle class, and small required changes in a couple of outside LLVM files. Also includes a modification to Mips target to simulate a 2-wide VLIW MIPS. The scheduler is really silly, I did not want to implement a scheduler, just the bundle class, and