There isn't any target-independent code to help form VLIW instruction words,
so you'll have to write code for your specific target to do that. Since
it's target-specific code, you can do whatever transforms are appropriate,
including rewriting instruction opcodes.
LLVM supports the notion of a "bundle", which might be helpful.
It's a set of multiple instructions which is treated as one instruction by
various backend passes. This allows representing the different parts of a VLIW
instruction word as separate instructions, but allows passes that don't
understand your target-specific bundles to treat it as one big instruction.
In-tree, you can look at the Hexagon backend to see how this works in practice.
-Eli
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Ronny
BarTov via llvm-dev
Sent: Sunday, January 19, 2020 1:38 AM
To: llvm-dev at lists.llvm.org
Subject: [EXT] [llvm-dev] extending LLVM
Hello,
in vliw architectures, the behavior of a machine command is fixed in whatever
vliw it is included.
In some cases, however, the appearance of some other specific commands within
the same vliw, affects the behavior of the original command,
or define a new way of operation such that the entire behavior of the vliw can
no longer be considered as the cumulative effect of the individual, separate,
commands.
examples for the above might be:
- allowing more than a single CC (condition code) changing command to be
present in the same vliw. a possible definition for such a case
might be to set the new CC to the logical OR of all the new values from the
commands in the vliw that write to the CC.
- forcing specific execution units.
suppose both I1 and I2 commands can be assigned to functional units
FU1 or FU2. we might insist that whenever I1 and I2 are in the same vliw,
then I1 must go to FU1 while I2 must go to FU2.
- two instructions can normally have a long encoding, but might use a combined,
shorter encoding that would make them fit together inside a single vliw.
Is there a systematic way to handle such cases in LLVM ?
Thx
ronny
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200120/41e37f5e/attachment.html>