[llvm-dev] extending LLVM

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] extending LLVM

Alex Brachet-Mialot via llvm-dev

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

 


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] extending LLVM

Alex Brachet-Mialot 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 <[hidden email]> On Behalf Of Ronny BarTov via llvm-dev
Sent: Sunday, January 19, 2020 1:38 AM
To: [hidden email]
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

 


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev