similar to: vectorization and vliw(very long instruction word)

Jonas, At this point, the DFA packetizer models a simple VLIW architecture and does not accommodate multiple stages. That's the reason for the behavior you're seeing. -Anshu --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation *From:*llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On Behalf Of *Jonas

On Apr 2, 2008, at 1:14 AM, Pertti Kellomäki wrote: > I am pretty excited about the recent activity on dependence > analysis. The only remaining problem from our point of view > is how to get the alias information to the back end instruction > scheduler. If I understand things correctly, the alias information > basically gets lost in the process of lowering to target >

Hi Jonas, > It is interesting to find this in the ARM backend, considering your answer. The ARM backend doesn't use the DFA packetizer. It's only used by Hexagon. At this point, there is no plan to address thisin the DFA packetizer since none of the supported targets needthe functionality. Thanks -Anshu --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,

I am pretty excited about the recent activity on dependence analysis. The only remaining problem from our point of view is how to get the alias information to the back end instruction scheduler. If I understand things correctly, the alias information basically gets lost in the process of lowering to target instructions. We are interested in the DSP domain, so we really need to get SIMD style

Hi Anshu, Would there be any interest in extending this algorithm to handling more extensive models, such as VLIW scheduling based on FU's and bundle space... ie handle multiple stages ? I might do it and commit, if there is acceptance and guidance... Jonas ________________________________ From: Anshuman Dasgupta [mailto:adasgupt at codeaurora.org] Sent: Tuesday, February 12, 2013 4:47 PM

Hi, I looked a bit through the mail archives, and found this question answered in Oct 2011 (see below). It is interesting to find this in the ARM backend, considering your answer. Can you give more information about for example is this a temporary deficiency in the DFAPacketizer? What is the IIC_iMOVi itinerary doing below? Thanks, Jonas Thu Oct 6 15:11:25 CDT 2011: Hello Hal. > Is there

Hi, I notice that there exist some classes for VLIW packetizing and other classes for VLIW scheduling. Apparently these classes share something in common. Can someone explain why they should have separate implementation (i.e., in different function passes)? Best regards. -- 杨勇勇 (Yang Yongyong)

Hi Yang, They have different implementations because they don't do the same thing and don't rely on the same structures. VLIW scheduling works on the SelectionDAG, right after the instruction selection, and it will schedule the DAG but it will not build any packet. The VLIW packetizer has been designed to work with machine instructions, using the ScheduleDAGInstr, and it does build

On Aug 9, 2012, at 10:09 AM, Sergei Larin <slarin at codeaurora.org> wrote: > Yang, > > This might not be such a tough choice on engineering side - one of the > LLVM differentiators is the ground-up, early introduced support for VLIW > specific features… Actually, LLVM lacked support for VLIW until fairly recently, and it has relatively few VLIW-specific features. Dan

Is there a VLIW support in LLVM? I found this, https://groups.google.com/forum/#!searchin/llvm-dev/VLIW, but it looks like it is not completely implemented. Specifically I'm interested in how instructions are bundled together. I can't seem to find it anywhere in the source code. Any help in resolving he issue is appreciated. -------------- next part -------------- An HTML attachment was

Hi, It seems the only one VLIW target Hexagon in LLVM 3.2 devel uses a straightforward way to emit its VLIW-style asm codes. It uses a list scheduler to schedule on DAG and a simple packetizer to wrap the emitted asm instructions. Both scheduling and packetizing work on basic blocks. so, is there any plan to implement better optimization methods such as trace scheduling, software pipelining, ...

But we are really striving to change it fast :) Dan, My comparative point was that LLVM has a greater potential to accommodate VLIW going forward than GCC does at this point. Would you agree to that? Sergei -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. > -----Original Message----- > From: Dan Gohman [mailto:gohman at apple.com] > Sent: Friday, August 10,

Larin, Thank you for telling me about this. Our lab is planning to design a VLIW DSP and has to make a choice between GCC and LLVM, for which I take responsibility. As we all know that GCC's codes possess a long history and has a somewhat bad learning curve, I suggest choosing LLVM. It seems now the only drawback is its poor support for VLIW architecture. And so if we can count on

Yang, There is work currently underway to add SW pipelining and some sort of global scheduling to Hexagon, but if there is some interest to it from other targets, it would be helpful to know. What is your involvement with this? Sergei Larin -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu

Has anyone attempted the port of LLVM to a VLIW architecture? Is there any publication about it? TIA -- Evandro Menezes Austin, TX emenezes at codeaurora.org Qualcomm Innovation Center, Inc is a member of Code Aurora Forum

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

hi guys I need to get llvm to support vliw architecture. Can you please point me in the right direction. we have managed to get it to compile into simple assemble and now need it to be able to schedule the instructions in parrallel. any help would be appreciated Regards Junior

Yang, This might not be such a tough choice on engineering side - one of the LLVM differentiators is the ground-up, early introduced support for VLIW specific features... As for the help offer - thanks... I'll definitely keep that in mind. The best help right now would be to keep on trying new VLIW related features as they got merged to LLVM tree and provide feedback... and we do plan to

VLIW (Very Long Instruction Word) is a long instruction format (called "group" hereafter) contains several instructions. These instructions are not dependent on each other and could be issued in a single cycle. At this moment there is no correspondent class for VLIW. MachineInstr object can only represent one instruction. Usually the number of instructions in a group is fixed. The

Kun, Thanks for the reply. I looked at it, but wasn't able to find where actual instruction bundling takes place, i.e. where exactly in the code they pack instruction into a single bundle. Do you know where it is done? I would really appreciate any pointers. Thanks. On Fri, Sep 25, 2015 at 4:37 PM, Kun Ling <kunling at lingcc.com> wrote: > Hi Rail, > For the VLIW support,