I’m trying to figure out how Hexagon (I’m using it as an example for my own VLIW) is handling bundles with 1 instruction, but I don’t quite get it. Here is the code that I have for a endPacket
// endPacket - End the current packet, bundle packet instructions and reset
// DFA state.
void VLIWPacketizerList::endPacket(MachineBasicBlock *MBB,
MachineInstr *MI) {
if (CurrentPacketMIs.size() > 1) {
MachineInstr *MIFirst = CurrentPacketMIs.front();
finalizeBundle(*MBB, MIFirst, MI);
}
CurrentPacketMIs.clear();
ResourceTracker->clearResources();
}
Based on this, it looks like packets with one instruction are not finalized (finalizeBundle is the one which inserts a BUNDLE instruction). So what happens with packets that have only 1 instruction? Is there a separate pass that creates a bundle from a single instruction?
Any help is appreciated.
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
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@lists.llvm.org
llvm-dev Info Page
I'm a little confused. If a bundle is supposed to have at least 2
instructions, what is the point of
VLIWPacketzierList::isSoloInstruction(...)? Say we have an instruction that
can't be bundled with anything, how would one form a packet from it?
In the machine IR, a bundle is a regular instruction, which happens to have other instructions inside of it. A basic block can have bundles mixed with non-bundled instructions. If you iterate over a basic block using MachineBasicBlock::iterator, you will not see the contents of bundles, just the BUNDLE opcode. For stepping into bundles you would need MachineBasicBlock::instr_iterator.
When it comes to the encoding of instructions for the hardware, the target-specific object-emission code must handle that properly. That happens later, on a yet another program representation, where instructions are of type MCInst, not MachineInstr.
-Krzysztof