search for: td857833

...locators. > > For VLIW, you probably want to number your packets instead of individual instructions. We don't have any VLIW support, so nobody has thought about how best to do it. People had discussed VLIW support before, you may have a look at this: http://old.nabble.com/VLIW-Scheduling-td857833.html I implemented the VLIW scheduling/register allocate in llvm backend like the way described in the above thread, and it work without any problem. best regards ether

...> For VLIW, you probably want to number your packets instead of individual instructions. We don't have any VLIW support, so nobody has thought about how best to do it. > > People had discussed VLIW support before, you may have a look at this: > http://old.nabble.com/VLIW-Scheduling-td857833.html Wow, that's old, but it is still a good way of solving the problem. It is the easiest way of smuggling packets through regalloc. > I implemented the VLIW scheduling/register allocate in llvm backend > like the way described in the above thread, and it work without any > problem....

On May 24, 2011, at 8:22 AM, Jonas Paulsson wrote: > Hi (Jakob), > > in reference to the prior message below, I have the following follow-up questions, as I also need a scheduling pass > prior to regalloc. I need to do this in order to set VLIW-flags, so that the RA is aware of several MI's > per cycle with a redefined LiveRange::overlap-function. On a multiple-issue cycle, a

Hi (Jakob), in reference to the prior message below, I have the following follow-up questions, as I also need a scheduling pass prior to regalloc. I need to do this in order to set VLIW-flags, so that the RA is aware of several MI's per cycle with a redefined LiveRange::overlap-function. On a multiple-issue cycle, a register that gets killed can be reused by another MI - these live ranges do