<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div>Since my focus is near the final phases of the compiler, Carlos' <br>suggestion was more eloquent to me and seem to be a good starting point <br>that I intend to investigate further.<br></div></blockquote><div><br></div><div>Ok, if you have any questions about the patch do not hesitate to ask :)</div><div><br></div><blockquote type="cite"><div>One hesitation that I have about sub-classing though is that base-class <br>objects may be destroyed and replaced by passes and thus the sub-class <br>information may be lost. This is not much of a problem at the final <br>stages, when there are fewer passes to worry about, but it may be <br>something difficult to control at early stages.<br></div></blockquote><div><br></div><div>They cannot really be destroyed, cause they get "hidden" somehow. The scheduling (quite simple in my code, but valid as example) removes the base MIs from the machine basic block and puts them inside the bundle. Packing them takes operands "off" the sub MIs, and assigns them to the bundle. So the MIs are no longer visible, no pass can touch or destroy them, they belong to no BB (thus no function), they are just stores inside the bundle for 2 reasons:</div><div>1) bundle just have operands, does not define an operation, so sub MIs need to be saved to record the opcodes.</div><div>2) it has to be possible to "recreate" the scalara MIs from the bundle, if needed.</div><div><br></div><div>BR,</div><div><br></div><div>Carlos</div><br><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font><br>On 10/25/11 09:50, Sergei Larin wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite">Carlos,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> Absolutely. And an addition to live range detection needs to be made aware of the global cycle... and it needs to be done regardless of representation methodology. Same for any pass that would care for packets. The important observation here IMHO is that "packetization" at early stage (before RA) is tentative, and RA can change the landscape, which must be somewhat finalized in Post RA scheduler. Nevertheless, I think one last pass, right before code emission is still needed to "clean up" the final schedule.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> I do not have a patch handy, it would have been easier to illustrate my proposal, but the fact of this discussion alone shows growing interest to the problem. I have a feeling that we might obtain a VLIW target/back end shortly, and then it would become a real (and burning) issue. This might be our chance to outperform GCC RISC centric philosophy in an elegant and powerful way.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> First step to healing is to recognize that we have an issue ;)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Sergei<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-----Original Message-----<br></blockquote><blockquote type="cite">From: Carlos Sánchez de La Lama [mailto:carlos.delalama@urjc.es]<br></blockquote><blockquote type="cite">Sent: Tuesday, October 25, 2011 4:24 AM<br></blockquote><blockquote type="cite">To: Sergei Larin<br></blockquote><blockquote type="cite">Cc: 'Evan Cheng'; 'Stripf, Timo'; 'LLVM Dev'<br></blockquote><blockquote type="cite">Subject: RE: [LLVMdev] VLIW Ports<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Hi Sergei,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"> What would you say to a some sort of a "global cycle" field/marker to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">determine all instructions scheduled at a certain "global" cycle. That way<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the "bundle"/packet/multiop can be identified at any time via a common<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">"global cycle" value.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">But RA would need to know about this global cycle field, right? Cause a<br></blockquote><blockquote type="cite">register can be reused in the same "global cycle" as it is killed.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Carlos<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">-----Original Message-----<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">From: <a href="mailto:llvmdev-bounces@cs.uiuc.edu">llvmdev-bounces@cs.uiuc.edu</a> [mailto:llvmdev-bounces@cs.uiuc.edu] On<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Behalf Of Carlos Sánchez de La Lama<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Sent: Monday, October 24, 2011 4:38 PM<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">To: Evan Cheng<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Cc: Stripf, Timo; LLVM Dev<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Subject: Re: [LLVMdev] VLIW Ports<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Hi Evan (and all),<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I think any implementation that makes a "bundle" a different entity from<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">MachineInstr is going to be difficult to use. All of the current backend<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">passes will have to taught to know about bundles.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The approach in the patch I sent (and I believe Timo's code works similar,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">according to his explanations) is precisely to make "bundles" no different<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">from MachineInstructions. They are MIs (a class derived from it), so all<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">other passes work transparently with them. For example, in my code register<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">allocator does not know it is allocating regs for a bundle, it sees it just<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">as a MI using a lot of registers. Of course, normal (scalar) passes can not<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">"inspect" inside bundles, and wont be able for example to put spilling code<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">into bundles or anything like that.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">But the good point is that bundles (which are MIs) and regular MIs can<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">coexist inside a MachineBasicBlock, and bundles can easily be "broken back"<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">to regular MIs when needed for some pass.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I think what we need is a concept of a sequence of fixed machine<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">instructions. Something that represent a number of MachineInstr's that are<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">scheduled as a unit, something that is never broken up by MI passes such as<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">branch folding. This is something that current targets can use to, for<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">example, pre-schedule instructions. This can be useful for macro-fusing<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">optimization. It can also be used for VLIW targets.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">There might be something I am missing, but I do not see the advantage here.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Even more, if you use sequences you need to find a way to tell the passes<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">how long a sequence is. On the other hand, if you use a class derived from<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">MI, the passes know already (from their POV their are just dealing with<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">MIs). You have of course to be careful on how you build the bundles so they<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">have the right properties matching those of the inner MIs, and there is<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">where the pack/unpack methods come in.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">BR<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Carlos<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Oct 21, 2011, at 4:52 PM, Stripf, Timo wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Hi all,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I worked the last 2 years on a LLVM back-end that supports clustered and<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">non-clustered VLIW architectures. I also wrote a paper about it that is<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">currently within the review process and is hopefully going to be accepted.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Here is a small summary how I realized VLIW support with a LLVM back-end. I<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">also used packing and unpacking of VLIW bundles. My implementations do not<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">require any modification of the LLVM core.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">To support VLIW I added two representations for VLIW instructions: packed<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">and unpacked representation. Within the unpacked representation a VLIW<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Bundle is separated by a NEXT instruction like it was done within the IA-64<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">back-end. The pack representation packs all instructions of one Bundle into<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">a single PACK instruction and I used this representation especially for the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">register allocation.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I used the following pass order for the clustered VLIW back-end:<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">DAG->DAG Pattern Instruction Selection<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">...<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Clustering (Not required for unicluster VLIW architectures)<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Scheduling<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Packing<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">...<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Register Allocation<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">...<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Prolog/Epilog Insertion& Frame Finalization<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Unpacking<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Reclustering<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">...<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Rescheduling (Splitting, Packing, Scheduling, Unpacking)<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Assembly Printer<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">In principle, it is possible to use the LLVM scheduler to generate<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">parallel code by providing a custom hazard recognizer that checks true data<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">dependencies of the current bundle. The scheduler has also the capability to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">output NEXT operations by using NoopHazard and outputting a NEXT instruction<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">instead of a NOP. However, the scheduler that is used within "DAG->DAG<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Pattern Instruction Selection" uses this glue mechanism and that could be<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">problematic since no NEXT instructions are issued between glued<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">instructions.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Within my back-end I added a parallelizing scheduling after "DAG->DAG<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Pattern Instruction Selection" by reusing the LLVM Post-RA scheduler<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">together with a custom hazard recognizer as explained. The Post-RA scheduler<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">works very well with some small modifications (special PHI instruction<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">handling and a small performance issue due to the high virtual register<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">numbers) also before register allocation.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Before register allocation the Packing pass converts the unpacked<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">representation outputted by the scheduler into the pack representation. So<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the register allocation sees the VLIW bundles as one instruction. After<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">"Prolog/Epilog Insertion& Frame Finalization" the Unpack pass converts the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">PACK instruction back to the unpacked representation. Thereby, instructions<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">that were added within the Register Allocation and Prolog/Epilog Insertion<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">are recognized and gets into one bundle since they are not parallelized.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">At the end (just before assembly output) I added several passes for doing<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">a rescheduling. First, the splitting pass tries to split a VLIW bundle into<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">single instructions (if possible). The Packing pass packs all Bundles with<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">more the one instruction into a single PACK instruction. The scheduler will<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">recognize the PACK instruction as a single scheduling unit. Scheduling is<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">nearly the same as before RA. Unpacking establishes again the unpacked<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">representation.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">If anyone is interested in more information please send me an email. I'm<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">also interested in increasing support for VLIW architectures within LLVM.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Kind regards,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Timo Stripf<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">-----Ursprüngliche Nachricht-----<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Von: <a href="mailto:llvmdev-bounces@cs.uiuc.edu">llvmdev-bounces@cs.uiuc.edu</a> [mailto:llvmdev-bounces@cs.uiuc.edu] Im<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Auftrag von Carlos Sánchez de La Lama<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Gesendet: Donnerstag, 6. Oktober 2011 13:14<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">An: LLVM Dev<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Betreff: Re: [LLVMdev] VLIW Ports<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Hi all,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">here is the current (unfinished) version of the VLIW support I mentioned.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">It is a patch over svn rev 141176. It includes the MachineInstrBundle class,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">and small required changes in a couple of outside LLVM files.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Also includes a modification to Mips target to simulate a 2-wide VLIW<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">MIPS. The scheduler is really silly, I did not want to implement a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">scheduler, just the bundle class, and the test scheduler is just provided as<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">an example.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Main thing still missing is to finish the "pack" and "unpack" methods in<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the bundle class. Right now it manages operands, both implicit and explicit,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">but it should also manage memory references, and update MIB flags acording<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">to sub-MI flags.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">For any question I would be glad to help.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">BR<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Carlos<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Tue, 2011-09-20 at 16:02 +0200, Carlos Sánchez de La Lama wrote:<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Hi,<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Has anyone attempted the port of LLVM to a VLIW architecture? Is<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">there any publication about it?<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I have developed a derivation of MachineInstr class, called<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">MachineInstrBundle, which is essnetially a VLIW-style machine<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">instruction which can store any MI on each "slot". After the<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">scheduling phase has grouped MIs in bundles, it has to call<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">MIB->pack() method, which takes operands from the MIs in the "slots"<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">and transfers them to the superinstruction. From this point on the<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">bundle is a normal machineinstruction which can be processed by other<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">LLVM passes (such as register allocation).<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The idea was to make a framework on top of which VLIW/ILP scheduling<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">could be studies using LLVM. It is not completely finished, but it is<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">more or less usable and works with a trivial scheduler in a synthetic<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">MIPS-VLIW architecture. Code emission does not work though (yet) so<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">bundles have to be unpacked prior to emission.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I was waiting to finish it to send a patch to the list, but if you are<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">interested I can send you a patch over svn of my current code.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">BR<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Carlos<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">LLVM Developers mailing list<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">LLVM Developers mailing list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">LLVM Developers mailing list<br></blockquote><blockquote type="cite"><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br></blockquote><blockquote type="cite"><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></div></blockquote></div><br></body></html>