[Libre-soc-isa] [Bug 532] discuss iterative approach for statistical analysis of effectiveness of Compressed PowerISA encoding

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Sat Nov 21 22:41:38 GMT 2020


--- Comment #12 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Alexandre Oliva from comment #10)
> modifying binutils so as to count opcodes that we'd like to compress could
> be done in basically two ways:
> - add to include/opcode/ppc.h:
> #define PPC_OPCODE_COMPRESS 0x800000000000ull
> - in opcodes/ppc-opc.c, mark the opcodes under powerpc_opcodes that are
> candidate for compression with '| PPC_OPCODE_COMPRESS' in FLAGS (the fourth
> column)
> - in opcodes/ppc-dis.c, modify increment_opcode_counter to check for this
> flag, apply any other constraints on the operands, and count the instruction
> as compressed if it fits
> This would require a quick recompilation for every experiment.

and that means if trying to compare those side-by-side it's very challenging. 
whereas a bunch of throwaway 50 line external python scripts is trivial to
rerun and compare.

> I'm not sure the latter effort is worth the additional convenience (if any)
> it would provide.  WDYT?

50 line python scripts reading stdin piped from objdump raw seems a lot easier.

> As for the extra constraints for insns to fit, that's where I haven't quite
> grasped what's proposed yet to be able to generalize the transformations and
> limits from 32-bit to 16- (and/or 10-?) bit opcodes, if there is a general
> rule at all.

OpenPOWER was never designed for dropping 16 bit on top of it.

RISCV RVC was ground-up designed for mixed 16/32.

we need to make some compromises: the 10 bit format makes best use of the
remaining bits whilst transitioning to "full" 16 bit mode.

the absolute simplest general rule is literally that from

at this stage we really do not want to get into the knock-on effects of
register allocation, effect on branches, and so on.  anything which, by the
very *existence* of Compressed, would result in the compiler emitting radically
altered assember, is *not* in scope at this stage: thst is too early.

however i would like to find out:

* word-aligned SP/FP immediates is enough
  (for 32 bit LD/ST)

  this confirms whether shifting the
  immediate by 2 bits is ok

* how many functions have 3, 4, 5 regs as

* what sort of range of immediates are
  there on cmpwi and cmpdi

  are they mostly low (small) or are they
  large.  are they mostly against zero

* which CRs are mostly used by branches

>  I'm still trying to get acquainted with the preexisting opcode
> formats of PowerISA (do we have a PDF for 3.1?

ah we are implementing v3.0B.  search "raptorcs wiki v3.0b OpenPOWER spec"
should come up top hit, no JS.

> and I'd rather not) to be better able to make sense of
> https://libre-soc.org/openpower/sv/16_bit_compressed/ (that I see has
> changed since I first went through it; moving target much? :-)

:) i use it to capture ongoing discussions.  if i don't they are lost pretty
much immediately.

to get a rapid overview of OPF v3.0B without needing to go through a 1300 page
PDF try these:


bear in mind FP is not added yet so not included in those tables.

You are receiving this mail because:
You are on the CC list for the bug.

More information about the Libre-SOC-ISA mailing list