[PATCH] D66210: [RFC/WIP][RISCV] Enable the machine outliner for RISC-V

Lewis Revill via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Oct 1 02:33:49 PDT 2019


lewis-revill added a comment.

In D66210#1684230 <https://reviews.llvm.org/D66210#1684230>, @apazos wrote:

> I have run a couple of standard workloads like SPEC. 
>  There is no correctness issue when enabling the MO feature (except for spec2000/twolf  which fails with/without MO).
>  The MO code size gains without compression are up to 7%. With compression enabled, most of the code size gain  is gone, and I see more code size increase.
>  It is possible it has to do with the SequenceSize we are estimating.
>  The reason we enable compression late is to have all paths - coming from codegen (LLVM IR), parsing, assembling .s or inline asm - go through the same mechanism for compression.
>  This is similar/compatible with GCC behavior, which relies on the external assembler to implement compression.
>  We can better estimate SequenceSize by checking if an instruction is compressable. We can modify the tablegen backend for compression emitter to generate a function that does the isCompressable check, but instead of using MCInst and MCOperands for the checks, we need to use MachineInstr and MachineOperand types.  I will try this solution. Another alternative is to compress LLVM IR code before running the machine outliner.


Hi Ana, thank you for this analysis, interestingly I still found significant benefits with compressed instructions enabled. It's worth noting that I was using Embench, which targets the embedded use case.

I'm not sure I quite follow what you mean when you say 'Another alternative is to compress LLVM IR code before running the machine outliner',  But did you make any progress with the 'isCompressible' method?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D66210/new/

https://reviews.llvm.org/D66210





More information about the llvm-commits mailing list