[riscv-port] RFR: 8278322: riscv: Support RVC: compressed instructions

Fei Yang fyang at openjdk.java.net
Thu Dec 9 06:41:22 UTC 2021


On Thu, 9 Dec 2021 06:11:15 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

> > > ### About our first scheme:
> > > We may mark some instructions as compressible by adding function arguments. But compressed instructions can be used in almost every place in the code cache, like C1, C2, interpreter, and stub code. The range is quite big -- for instance, after some time we may want to compress some intrinsics, say, `C2_MacroAssembler::string_indexof_char_short()`.
> > > After `addi(Rd, Rs, imm)` becomes `addi(Rd, Rs, imm, bool compressible)`, it will be
> > > ```
> > > bind(MATCH1);
> > > addi(index, index, 1);   ->    addi(index, index, 1, true);
> > > j(MATCH);                ->    j(MATCH, true);
> > >
> > > bind(MATCH2);
> > > addi(index, index, 2);   ->    addi(index, index, 2, true);
> > > j(MATCH);                ->    j(MATCH, true)
> > >
> > > bind(MATCH3);
> > > addi(index, index, 3);   ->   ...
> > > j(MATCH);
> > >
> > > bind(MATCH4);
> > > addi(index, index, 4);
> > > j(MATCH);
> > >
> > > bind(MATCH5);
> > > addi(index, index, 5);
> > > j(MATCH);
> > > ```
> >
> >
> > That's exactly what I mean :-) And this could be carried out incrementally, module by module.
> > > We might not add extra explicit arguments to them since this may make maintenance quite hard. :-)
> >
> >
> > No. Passing one extra argument here won't affect future code maintainance in anyway here. In fact, I think this will make reviewer/maintainer's life easier since this makes it explict the places where it's safe to do compress.
>
> Thanks for your quick response, Felix. In fact, I could not realize the philosophy inside this strategy -- so just one double-check: after this, if we define `#define COMPRESSIBLE true` here, I think nearly all the RISC-V backend will be full of `inst(Rd, Rs, ..., COMPRESSIBLE)` everywhere, which means the whole backend's code will be fully coupling with a single RISC-V extension. Hmm... it seems quite unacceptable in my opinion -- could you please simply explain it further for me?

In fact, I am not expecting we catch all the possible places in the backend converting to compressed instructions.
I guess maybe the best places to do this would be C1 and C2.
It doesn't make much sense to me to do this kind of thing for code stubs, template interpreter, runtime, etc.
We might churn too much without little gain.
Code size might be an issue for 32-bit RV32G embedded systems, but I feel it's less likely an big issue for 64-bit systems like RV64G. I even doubt future chip vendors would ship this RVC feature for RV64G systems.

-------------

PR: https://git.openjdk.java.net/riscv-port/pull/24



More information about the riscv-port-dev mailing list