Merging upstream version 5.6.2.

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 755 insertions, 0 deletions

diff --git a/src/liblzma/simple/riscv.c b/src/liblzma/simple/riscv.c
new file mode 100644
index 0000000..b18df8b
--- /dev/null
+++ b/src/liblzma/simple/riscv.c
@@ -0,0 +1,755 @@
+// SPDX-License-Identifier: 0BSD
+
+///////////////////////////////////////////////////////////////////////////////
+//
+/// \file       riscv.c
+/// \brief      Filter for 32-bit/64-bit little/big endian RISC-V binaries
+///
+/// This converts program counter relative addresses in function calls
+/// (JAL, AUIPC+JALR), address calculation of functions and global
+/// variables (AUIPC+ADDI), loads (AUIPC+load), and stores (AUIPC+store).
+///
+/// For AUIPC+inst2 pairs, the paired instruction checking is fairly relaxed.
+/// The paired instruction opcode must only have its lowest two bits set,
+/// meaning it will convert any paired instruction that is not a 16-bit
+/// compressed instruction. This was shown to be enough to keep the number
+/// of false matches low while improving code size and speed.
+//
+//  Authors:    Lasse Collin
+//              Jia Tan
+//
+//  Special thanks:
+//
+//    - Chien Wong <m@xv97.com> provided a few early versions of RISC-V
+//      filter variants along with test files and benchmark results.
+//
+//    - Igor Pavlov helped a lot in the filter design, getting it both
+//      faster and smaller. The implementation here is still independently
+//      written, not based on LZMA SDK.
+//
+///////////////////////////////////////////////////////////////////////////////
+
+/*
+
+RISC-V filtering
+================
+
+    RV32I and RV64I, possibly combined with extensions C, Zfh, F, D,
+    and Q, are identical enough that the same filter works for both.
+
+    The instruction encoding is always little endian, even on systems
+    with big endian data access. Thus the same filter works for both
+    endiannesses.
+
+    The following instructions have program counter relative
+    (pc-relative) behavior:
+
+JAL
+---
+
+    JAL is used for function calls (including tail calls) and
+    unconditional jumps within functions. Jumps within functions
+    aren't useful to filter because the absolute addresses often
+    appear only once or at most a few times. Tail calls and jumps
+    within functions look the same to a simple filter so neither
+    are filtered, that is, JAL x0 is ignored (the ABI name of the
+    register x0 is "zero").
+
+    Almost all calls store the return address to register x1 (ra)
+    or x5 (t0). To reduce false matches when the filter is applied
+    to non-code data, only the JAL instructions that use x1 or x5
+    are converted. JAL has pc-relative range of +/-1 MiB so longer
+    calls and jumps need another method (AUIPC+JALR).
+
+C.J and C.JAL
+-------------
+
+    C.J and C.JAL have pc-relative range of +/-2 KiB.
+
+    C.J is for tail calls and jumps within functions and isn't
+    filtered for the reasons mentioned for JAL x0.
+
+    C.JAL is an RV32C-only instruction. Its encoding overlaps with
+    RV64C-only C.ADDIW which is a common instruction. So if filtering
+    C.JAL was useful (it wasn't tested) then a separate filter would
+    be needed for RV32 and RV64. Also, false positives would be a
+    significant problem when the filter is applied to non-code data
+    because C.JAL needs only five bits to match. Thus, this filter
+    doesn't modify C.JAL instructions.
+
+BEQ, BNE, BLT, BGE, BLTU, BGEU, C.BEQZ, and C.BNEZ
+--------------------------------------------------
+
+    These are conditional branches with pc-relative range
+    of +/-4 KiB (+/-256 B for C.*). The absolute addresses often
+    appear only once and very short distances are the most common,
+    so filtering these instructions would make compression worse.
+
+AUIPC with rd != x0
+-------------------
+
+    AUIPC is paired with a second instruction (inst2) to do
+    pc-relative jumps, calls, loads, stores, and for taking
+    an address of a symbol. AUIPC has a 20-bit immediate and
+    the possible inst2 choices have a 12-bit immediate.
+
+    AUIPC stores pc + 20-bit signed immediate to a register.
+    The immediate encodes a multiple of 4 KiB so AUIPC itself
+    has a pc-relative range of +/-2 GiB. AUIPC does *NOT* set
+    the lowest 12 bits of the result to zero! This means that
+    the 12-bit immediate in inst2 cannot just include the lowest
+    12 bits of the absolute address as is; the immediate has to
+    compensate for the lowest 12 bits that AUIPC copies from the
+    program counter. This means that a good filter has to convert
+    not only AUIPC but also the paired inst2.
+
+    A strict filter would focus on filtering the following
+    AUIPC+inst2 pairs:
+
+      - AUIPC+JALR: Function calls, including tail calls.
+
+      - AUIPC+ADDI: Calculating the address of a function
+        or a global variable.
+
+      - AUIPC+load/store from the base instruction sets
+        (RV32I, RV64I) or from the floating point extensions
+        Zfh, F, D, and Q:
+          * RV32I: LB, LH, LW, LBU, LHU, SB, SH, SW
+          * RV64I has also: LD, LWU, SD
+          * Zfh: FLH, FSH
+          * F: FLW, FSW
+          * D: FLD, FSD
+          * Q: FLQ, FSQ
+
+    NOTE: AUIPC+inst2 can only be a pair if AUIPC's rd specifies
+    the same register as inst2's rs1.
+
+    Instead of strictly accepting only the above instructions as inst2,
+    this filter uses a much simpler condition: the lowest two bits of
+    inst2 must be set, that is, inst2 must not be a 16-bit compressed
+    instruction. So this will accept all 32-bit and possible future
+    extended instructions as a pair to AUIPC if the bits in AUIPC's
+    rd [11:7] match the bits [19:15] in inst2 (the bits that I-type and
+    S-type instructions use for rs1). Testing showed that this relaxed
+    condition for inst2 did not consistently or significantly affect
+    compression ratio but it reduced code size and improved speed.
+
+    Additionally, the paired instruction is always treated as an I-type
+    instruction. The S-type instructions used by stores (SB, SH, SW,
+    etc.) place the lowest 5 bits of the immediate in a different
+    location than I-type instructions. AUIPC+store pairs are less
+    common than other pairs, and testing showed that the extra
+    code required to handle S-type instructions was not worth the
+    compression ratio gained.
+
+    AUIPC+inst2 don't necessarily appear sequentially next to each
+    other although very often they do. Especially AUIPC+JALR are
+    sequential as that may allow instruction fusion in processors
+    (and perhaps help branch prediction as a fused AUIPC+JALR is
+    a direct branch while JALR alone is an indirect branch).
+
+    Clang 16 can generate code where AUIPC+inst2 is split:
+
+      - AUIPC is outside a loop and inst2 (load/store) is inside
+        the loop. This way the AUIPC instruction needs to be
+        executed only once.
+
+      - Load-modify-store may have AUIPC for the load and the same
+        AUIPC-result is used for the store too. This may get combined
+        with AUIPC being outside the loop.
+
+      - AUIPC is before a conditional branch and inst2 is hundreds
+        of bytes away at the branch target.
+
+      - Inner and outer pair:
+
+            auipc   a1,0x2f
+            auipc   a2,0x3d
+            ld      a2,-500(a2)
+            addi    a1,a1,-233
+
+      - Many split pairs with an untaken conditional branch between:
+
+            auipc   s9,0x1613   # Pair 1
+            auipc   s4,0x1613   # Pair 2
+            auipc   s6,0x1613   # Pair 3
+            auipc   s10,0x1613  # Pair 4
+            beqz    a5,a3baae
+            ld      a0,0(a6)
+            ld      a6,246(s9)  # Pair 1
+            ld      a1,250(s4)  # Pair 2
+            ld      a3,254(s6)  # Pair 3
+            ld      a4,258(s10) # Pair 4
+
+    It's not possible to find all split pairs in a filter like this.
+    At least in 2024, simple sequential pairs are 99 % of AUIPC uses
+    so filtering only such pairs gives good results and makes the
+    filter simpler. However, it's possible that future compilers will
+    produce different code where sequential pairs aren't as common.
+
+    This filter doesn't convert AUIPC instructions alone because:
+
+    (1) The conversion would be off-by-one (or off-by-4096) half the
+        time because the lowest 12 bits from inst2 (inst2_imm12)
+        aren't known. We only know that the absolute address is
+        pc + AUIPC_imm20 + [-2048, +2047] but there is no way to
+        know the exact 4096-byte multiple (or 4096 * n + 2048):
+        there are always two possibilities because AUIPC copies
+        the 12 lowest bits from pc instead of zeroing them.
+
+        NOTE: The sign-extension of inst2_imm12 adds a tiny bit
+        of extra complexity to AUIPC math in general but it's not
+        the reason for this problem. The sign-extension only changes
+        the relative position of the pc-relative 4096-byte window.
+
+    (2) Matching AUIPC instruction alone requires only seven bits.
+        When the filter is applied to non-code data, that leads
+        to many false positives which make compression worse.
+        As long as most AUIPC+inst2 pairs appear as two consecutive
+        instructions, converting only such pairs gives better results.
+
+    In assembly, AUIPC+inst2 tend to look like this:
+
+        # Call:
+        auipc   ra, 0x12345
+        jalr    ra, -42(ra)
+
+        # Tail call:
+        auipc   t1, 0x12345
+        jalr    zero, -42(t1)
+
+        # Getting the absolute address:
+        auipc   a0, 0x12345
+        addi    a0, a0, -42
+
+        # rd of inst2 isn't necessarily the same as rs1 even
+        # in cases where there is no reason to preserve rs1.
+        auipc   a0, 0x12345
+        addi    a1, a0, -42
+
+    As of 2024, 16-bit instructions from the C extension don't
+    appear as inst2. The RISC-V psABI doesn't list AUIPC+C.* as
+    a linker relaxation type explicitly but it's not disallowed
+    either. Usefulness is limited as most of the time the lowest
+    12 bits won't fit in a C instruction. This filter doesn't
+    support AUIPC+C.* combinations because this makes the filter
+    simpler, there are no test files, and it hopefully will never
+    be needed anyway.
+
+    (Compare AUIPC to ARM64 where ADRP does set the lowest 12 bits
+    to zero. The paired instruction has the lowest 12 bits of the
+    absolute address as is in a zero-extended immediate. Thus the
+    ARM64 filter doesn't need to care about the instructions that
+    are paired with ADRP. An off-by-4096 issue can still occur if
+    the code section isn't aligned with the filter's start offset.
+    It's not a problem with standalone ELF files but Windows PE
+    files need start_offset=3072 for best results. Also, a .tar
+    stores files with 512-byte alignment so most of the time it
+    won't be the best for ARM64.)
+
+AUIPC with rd == x0
+-------------------
+
+    AUIPC instructions with rd=x0 are reserved for HINTs in the base
+    instruction set. Such AUIPC instructions are never filtered.
+
+    As of January 2024, it seems likely that AUIPC with rd=x0 will
+    be used for landing pads (pseudoinstruction LPAD). LPAD is used
+    to mark valid targets for indirect jumps (for JALR), for example,
+    beginnings of functions. The 20-bit immediate in LPAD instruction
+    is a label, not a pc-relative address. Thus it would be
+    counterproductive to convert AUIPC instructions with rd=x0.
+
+    Often the next instruction after LPAD won't have rs1=x0 and thus
+    the filtering would be skipped for that reason alone. However,
+    it's not good to rely on this. For example, consider a function
+    that begins like this:
+
+        int foo(int i)
+        {
+            if (i <= 234) {
+                ...
+            }
+
+    A compiler may generate something like this:
+
+        lpad    0x54321
+        li      a5, 234
+        bgt     a0, a5, .L2
+
+    Converting the pseudoinstructions to raw instructions:
+
+        auipc   x0, 0x54321
+        addi    x15, x0, 234
+        blt     x15, x10, .L2
+
+    In this case the filter would undesirably convert the AUIPC+ADDI
+    pair if the filter didn't explicitly skip AUIPC instructions
+    that have rd=x0.
+
+*/
+
+
+#include "simple_private.h"
+
+
+// This checks two conditions at once:
+//    - AUIPC rd == inst2 rs1.
+//    - inst2 opcode has the lowest two bits set.
+//
+// The 8 bit left shift aligns the rd of AUIPC with the rs1 of inst2.
+// By XORing the registers, any non-zero value in those bits indicates the
+// registers are not equal and thus not an AUIPC pair. Subtracting 3 from
+// inst2 will zero out the first two opcode bits only when they are set.
+// The mask tests if any of the register or opcode bits are set (and thus
+// not an AUIPC pair).
+//
+// Alternative expression: (((((auipc) << 8) ^ (inst2)) & 0xF8003) != 3)
+#define NOT_AUIPC_PAIR(auipc, inst2) \
+	((((auipc) << 8) ^ ((inst2) - 3)) & 0xF8003)
+
+// This macro checks multiple conditions:
+//   (1) AUIPC rd [11:7] == x2 (special rd value).
+//   (2) AUIPC bits 12 and 13 set (the lowest two opcode bits of packed inst2).
+//   (3) inst2_rs1 doesn't equal x0 or x2 because the opposite
+//       conversion is only done when
+//       auipc_rd != x0 &&
+//       auipc_rd != x2 &&
+//       auipc_rd == inst2_rs1.
+//
+// The left-hand side takes care of (1) and (2).
+//   (a) The lowest 7 bits are already known to be AUIPC so subtracting 0x17
+//       makes those bits zeros.
+//   (b) If AUIPC rd equals x2, subtracting 0x100 makes bits [11:7] zeros.
+//       If rd doesn't equal x2, then there will be at least one non-zero bit
+//       and the next step (c) is irrelevant.
+//   (c) If the lowest two opcode bits of the packed inst2 are set in [13:12],
+//       then subtracting 0x3000 will make those bits zeros. Otherwise there
+//       will be at least one non-zero bit.
+//
+// The shift by 18 removes the high bits from the final '>=' comparison and
+// ensures that any non-zero result will be larger than any possible result
+// from the right-hand side of the comparison. The cast ensures that the
+// left-hand side didn't get promoted to a larger type than uint32_t.
+//
+// On the right-hand side, inst2_rs1 & 0x1D will be non-zero as long as
+// inst2_rs1 is not x0 or x2.
+//
+// The final '>=' comparison will make the expression true if:
+//   - The subtraction caused any bits to be set (special AUIPC rd value not
+//     used or inst2 opcode bits not set). (non-zero >= non-zero or 0)
+//   - The subtraction did not cause any bits to be set but inst2_rs1 was
+//     x0 or x2. (0 >= 0)
+#define NOT_SPECIAL_AUIPC(auipc, inst2_rs1) \
+	((uint32_t)(((auipc) - 0x3117) << 18) >= ((inst2_rs1) & 0x1D))
+
+
+// The encode and decode functions are split for this filter because of the
+// AUIPC+inst2 filtering. This filter design allows a decoder-only
+// implementation to be smaller than alternative designs.
+
+#ifdef HAVE_ENCODER_RISCV
+static size_t
+riscv_encode(void *simple lzma_attribute((__unused__)),
+		uint32_t now_pos,
+		bool is_encoder lzma_attribute((__unused__)),
+		uint8_t *buffer, size_t size)
+{
+	// Avoid using i + 8 <= size in the loop condition.
+	//
+	// NOTE: If there is a JAL in the last six bytes of the stream, it
+	// won't be converted. This is intentional to keep the code simpler.
+	if (size < 8)
+		return 0;
+
+	size -= 8;
+
+	size_t i;
+
+	// The loop is advanced by 2 bytes every iteration since the
+	// instruction stream may include 16-bit instructions (C extension).
+	for (i = 0; i <= size; i += 2) {
+		uint32_t inst = buffer[i];
+
+		if (inst == 0xEF) {
+			// JAL
+			const uint32_t b1 = buffer[i + 1];
+
+			// Only filter rd=x1(ra) and rd=x5(t0).
+			if ((b1 & 0x0D) != 0)
+				continue;
+
+			// The 20-bit immediate is in four pieces.
+			// The encoder stores it in big endian form
+			// since it improves compression slightly.
+			const uint32_t b2 = buffer[i + 2];
+			const uint32_t b3 = buffer[i + 3];
+			const uint32_t pc = now_pos + (uint32_t)i;
+
+// The following chart shows the highest three bytes of JAL, focusing on
+// the 20-bit immediate field [31:12]. The first row of numbers is the
+// bit position in a 32-bit little endian instruction. The second row of
+// numbers shows the order of the immediate field in a J-type instruction.
+// The last row is the bit number in each byte.
+//
+// To determine the amount to shift each bit, subtract the value in
+// the last row from the value in the second last row. If the number
+// is positive, shift left. If negative, shift right.
+//
+// For example, at the rightmost side of the chart, the bit 4 in b1 is
+// the bit 12 of the address. Thus that bit needs to be shifted left
+// by 12 - 4 = 8 bits to put it in the right place in the addr variable.
+//
+// NOTE: The immediate of a J-type instruction holds bits [20:1] of
+// the address. The bit [0] is always 0 and not part of the immediate.
+//
+// |          b3             |          b2             |          b1         |
+// | 31 30 29 28 27 26 25 24 | 23 22 21 20 19 18 17 16 | 15 14 13 12 x x x x |
+// | 20 10  9  8  7  6  5  4 |  3  2  1 11 19 18 17 16 | 15 14 13 12 x x x x |
+// |  7  6  5  4  3  2  1  0 |  7  6  5  4  3  2  1  0 |  7  6  5  4 x x x x |
+
+			uint32_t addr = ((b1 & 0xF0) << 8)
+					| ((b2 & 0x0F) << 16)
+					| ((b2 & 0x10) << 7)
+					| ((b2 & 0xE0) >> 4)
+					| ((b3 & 0x7F) << 4)
+					| ((b3 & 0x80) << 13);
+
+			addr += pc;
+
+			buffer[i + 1] = (uint8_t)((b1 & 0x0F)
+					| ((addr >> 13) & 0xF0));
+
+			buffer[i + 2] = (uint8_t)(addr >> 9);
+			buffer[i + 3] = (uint8_t)(addr >> 1);
+
+			// The "-2" is included because the for-loop will
+			// always increment by 2. In this case, we want to
+			// skip an extra 2 bytes since we used 4 bytes
+			// of input.
+			i += 4 - 2;
+
+		} else if ((inst & 0x7F) == 0x17) {
+			// AUIPC
+			inst |= (uint32_t)buffer[i + 1] << 8;
+			inst |= (uint32_t)buffer[i + 2] << 16;
+			inst |= (uint32_t)buffer[i + 3] << 24;
+
+			// Branch based on AUIPC's rd. The bitmask test does
+			// the same thing as this:
+			//
+			//     const uint32_t auipc_rd = (inst >> 7) & 0x1F;
+			//     if (auipc_rd != 0 && auipc_rd != 2) {
+ 			if (inst & 0xE80) {
+				// AUIPC's rd doesn't equal x0 or x2.
+
+				// Check if AUIPC+inst2 are a pair.
+				uint32_t inst2 = read32le(buffer + i + 4);
+
+				if (NOT_AUIPC_PAIR(inst, inst2)) {
+					// The NOT_AUIPC_PAIR macro allows
+					// a false AUIPC+AUIPC pair if the
+					// bits [19:15] (where rs1 would be)
+					// in the second AUIPC match the rd
+					// of the first AUIPC.
+					//
+					// We must skip enough forward so
+					// that the first two bytes of the
+					// second AUIPC cannot get converted.
+					// Such a conversion could make the
+					// current pair become a valid pair
+					// which would desync the decoder.
+					//
+					// Skipping six bytes is enough even
+					// though the above condition looks
+					// at the lowest four bits of the
+					// buffer[i + 6] too. This is safe
+					// because this filter never changes
+					// those bits if a conversion at
+					// that position is done.
+					i += 6 - 2;
+					continue;
+				}
+
+				// Convert AUIPC+inst2 to a special format:
+				//
+				//   - The lowest 7 bits [6:0] retain the
+				//     AUIPC opcode.
+				//
+				//   - The rd [11:7] is set to x2(sp). x2 is
+				//     used as the stack pointer so AUIPC with
+				//     rd=x2 should be very rare in real-world
+				//     executables.
+				//
+				//   - The remaining 20 bits [31:12] (that
+				//     normally hold the pc-relative immediate)
+				//     are used to store the lowest 20 bits of
+				//     inst2. That is, the 12-bit immediate of
+				//     inst2 is not included.
+				//
+				//   - The location of the original inst2 is
+				//     used to store the 32-bit absolute
+				//     address in big endian format. Compared
+				//     to the 20+12-bit split encoding, this
+				//     results in a longer uninterrupted
+				//     sequence of identical common bytes
+				//     when the same address is referred
+				//     with different instruction pairs
+				//     (like AUIPC+LD vs. AUIPC+ADDI) or
+				//     when the occurrences of the same
+				//     pair use different registers. When
+				//     referring to adjacent memory locations
+				//     (like function calls that go via the
+				//     ELF PLT), in big endian order only the
+				//     last 1-2 bytes differ; in little endian
+				//     the differing 1-2 bytes would be in the
+				//     middle of the 8-byte sequence.
+				//
+				// When reversing the transformation, the
+				// original rd of AUIPC can be restored
+				// from inst2's rs1 as they are required to
+				// be the same.
+
+				// Arithmetic right shift makes sign extension
+				// trivial but (1) it's implementation-defined
+				// behavior (C99/C11/C23 6.5.7-p5) and so is
+				// (2) casting unsigned to signed (6.3.1.3-p3).
+				//
+				// One can check for (1) with
+				//
+				//     if ((-1 >> 1) == -1) ...
+				//
+				// but (2) has to be checked from the
+				// compiler docs. GCC promises that (1)
+				// and (2) behave in the common expected
+				// way and thus
+				//
+				//     addr += (uint32_t)(
+				//             (int32_t)inst2 >> 20);
+				//
+				// does the same as the code below. But since
+				// the 100 % portable way is only a few bytes
+				// bigger code and there is no real speed
+				// difference, let's just use that, especially
+				// since the decoder doesn't need this at all.
+				uint32_t addr = inst & 0xFFFFF000;
+				addr += (inst2 >> 20)
+						- ((inst2 >> 19) & 0x1000);
+
+				addr += now_pos + (uint32_t)i;
+
+				// Construct the first 32 bits:
+				//   [6:0]    AUIPC opcode
+				//   [11:7]   Special AUIPC rd = x2
+				//   [31:12]  The lowest 20 bits of inst2
+				inst = 0x17 | (2 << 7) | (inst2 << 12);
+
+				write32le(buffer + i, inst);
+
+				// The second 32 bits store the absolute
+				// address in big endian order.
+				write32be(buffer + i + 4, addr);
+			} else {
+				// AUIPC's rd equals x0 or x2.
+				//
+				// x0 indicates a landing pad (LPAD).
+				// It's always skipped.
+				//
+				// AUIPC with rd == x2 is used for the special
+				// format as explained above. When the input
+				// contains a byte sequence that matches the
+				// special format, "fake" decoding must be
+				// done to keep the filter bijective (that
+				// is, safe to apply on arbitrary data).
+				//
+				// See the "x0 or x2" section in riscv_decode()
+				// for how the "real" decoding is done. The
+				// "fake" decoding is a simplified version
+				// of "real" decoding with the following
+				// differences (these reduce code size of
+				// the decoder):
+				// (1) The lowest 12 bits aren't sign-extended.
+				// (2) No address conversion is done.
+				// (3) Big endian format isn't used (the fake
+				//     address is in little endian order).
+
+				// Check if inst matches the special format.
+				const uint32_t fake_rs1 = inst >> 27;
+
+				if (NOT_SPECIAL_AUIPC(inst, fake_rs1)) {
+					i += 4 - 2;
+					continue;
+				}
+
+				const uint32_t fake_addr =
+						read32le(buffer + i + 4);
+
+				// Construct the second 32 bits:
+				//   [19:0]   Upper 20 bits from AUIPC
+				//   [31:20]  The lowest 12 bits of fake_addr
+				const uint32_t fake_inst2 = (inst >> 12)
+						| (fake_addr << 20);
+
+				// Construct new first 32 bits from:
+				//   [6:0]   AUIPC opcode
+				//   [11:7]  Fake AUIPC rd = fake_rs1
+				//   [31:12] The highest 20 bits of fake_addr
+				inst = 0x17 | (fake_rs1 << 7)
+					| (fake_addr & 0xFFFFF000);
+
+				write32le(buffer + i, inst);
+				write32le(buffer + i + 4, fake_inst2);
+			}
+
+			i += 8 - 2;
+		}
+	}
+
+	return i;
+}
+
+
+extern lzma_ret
+lzma_simple_riscv_encoder_init(lzma_next_coder *next,
+		const lzma_allocator *allocator,
+		const lzma_filter_info *filters)
+{
+	return lzma_simple_coder_init(next, allocator, filters,
+			&riscv_encode, 0, 8, 2, true);
+}
+#endif
+
+
+#ifdef HAVE_DECODER_RISCV
+static size_t
+riscv_decode(void *simple lzma_attribute((__unused__)),
+		uint32_t now_pos,
+		bool is_encoder lzma_attribute((__unused__)),
+		uint8_t *buffer, size_t size)
+{
+	if (size < 8)
+		return 0;
+
+	size -= 8;
+
+	size_t i;
+	for (i = 0; i <= size; i += 2) {
+		uint32_t inst = buffer[i];
+
+		if (inst == 0xEF) {
+			// JAL
+			const uint32_t b1 = buffer[i + 1];
+
+			// Only filter rd=x1(ra) and rd=x5(t0).
+			if ((b1 & 0x0D) != 0)
+				continue;
+
+			const uint32_t b2 = buffer[i + 2];
+			const uint32_t b3 = buffer[i + 3];
+			const uint32_t pc = now_pos + (uint32_t)i;
+
+// |          b3             |          b2             |          b1         |
+// | 31 30 29 28 27 26 25 24 | 23 22 21 20 19 18 17 16 | 15 14 13 12 x x x x |
+// | 20 10  9  8  7  6  5  4 |  3  2  1 11 19 18 17 16 | 15 14 13 12 x x x x |
+// |  7  6  5  4  3  2  1  0 |  7  6  5  4  3  2  1  0 |  7  6  5  4 x x x x |
+
+			uint32_t addr = ((b1 & 0xF0) << 13)
+					| (b2 << 9) | (b3 << 1);
+
+			addr -= pc;
+
+			buffer[i + 1] = (uint8_t)((b1 & 0x0F)
+					| ((addr >> 8) & 0xF0));
+
+			buffer[i + 2] = (uint8_t)(((addr >> 16) & 0x0F)
+					| ((addr >> 7) & 0x10)
+					| ((addr << 4) & 0xE0));
+
+			buffer[i + 3] = (uint8_t)(((addr >> 4) & 0x7F)
+					| ((addr >> 13) & 0x80));
+
+			i += 4 - 2;
+
+		} else if ((inst & 0x7F) == 0x17) {
+			// AUIPC
+			uint32_t inst2;
+
+			inst |= (uint32_t)buffer[i + 1] << 8;
+			inst |= (uint32_t)buffer[i + 2] << 16;
+			inst |= (uint32_t)buffer[i + 3] << 24;
+
+			if (inst & 0xE80) {
+				// AUIPC's rd doesn't equal x0 or x2.
+
+				// Check if it is a "fake" AUIPC+inst2 pair.
+				inst2 = read32le(buffer + i + 4);
+
+				if (NOT_AUIPC_PAIR(inst, inst2)) {
+					i += 6 - 2;
+					continue;
+				}
+
+				// Decode (or more like re-encode) the "fake"
+				// pair. The "fake" format doesn't do
+				// sign-extension, address conversion, or
+				// use big endian. (The use of little endian
+				// allows sharing the write32le() calls in
+				// the decoder to reduce code size when
+				// unaligned access isn't supported.)
+				uint32_t addr = inst & 0xFFFFF000;
+				addr += inst2 >> 20;
+
+				inst = 0x17 | (2 << 7) | (inst2 << 12);
+				inst2 = addr;
+			} else {
+				// AUIPC's rd equals x0 or x2.
+
+				// Check if inst matches the special format
+				// used by the encoder.
+				const uint32_t inst2_rs1 = inst >> 27;
+
+				if (NOT_SPECIAL_AUIPC(inst, inst2_rs1)) {
+					i += 4 - 2;
+					continue;
+				}
+
+				// Decode the "real" pair.
+				uint32_t addr = read32be(buffer + i + 4);
+
+				addr -= now_pos + (uint32_t)i;
+
+				// The second instruction:
+				//   - Get the lowest 20 bits from inst.
+				//   - Add the lowest 12 bits of the address
+				//     as the immediate field.
+				inst2 = (inst >> 12) | (addr << 20);
+
+				// AUIPC:
+				//   - rd is the same as inst2_rs1.
+				//   - The sign extension of the lowest 12 bits
+				//     must be taken into account.
+				inst = 0x17 | (inst2_rs1 << 7)
+					| ((addr + 0x800) & 0xFFFFF000);
+			}
+
+			// Both decoder branches write in little endian order.
+			write32le(buffer + i, inst);
+			write32le(buffer + i + 4, inst2);
+
+			i += 8 - 2;
+		}
+	}
+
+	return i;
+}
+
+
+extern lzma_ret
+lzma_simple_riscv_decoder_init(lzma_next_coder *next,
+		const lzma_allocator *allocator,
+		const lzma_filter_info *filters)
+{
+	return lzma_simple_coder_init(next, allocator, filters,
+			&riscv_decode, 0, 8, 2, false);
+}
+#endif