[llvm-dev] extending LLVM

[Eli Friedman via llvm-dev]

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>