On Fri, 24 Jul 2026 10:18:44 -0700 Brian Cain <[email protected]> wrote: > > has_valid_slot_assignment() rejected any packet with two instructions > assigned to the same slot. That is too strict. When a memory > instruction is encoded before a slot-flexible instruction in a packet, > the descending slot assignment places the memory op in slot 1 and the > other in slot 0, then the "mem insns to slot 0" fixup moves the memory > op to slot 0 as well, leaving both in slot 0. Such a packet is valid > and executes correctly, but the uniqueness test flagged it as > HEX_CAUSE_INVALID_PACKET, raising SIGILL in linux-user and a precise > exception in system mode. > > For example this packet, with the load encoded first, was wrongly > rejected: > > { r6 = memw(r3+#-4) > r7 = #0x4ae6 } > > Replace the uniqueness test with a slot-exhaustion check: walk the > instructions in encoding order handing out slots in strictly decreasing > order and fail only if an instruction has no valid slot at or below the > running slot. This accepts packets that legally share a slot while > still rejecting genuinely unassignable packets, such as a memory > instruction grouped with a duplex, or a load followed by an instruction > that requires a high slot. > > Signed-off-by: Brian Cain <[email protected]> > --- > target/hexagon/decode.c | 30 ++++++++++++++++++++++-------- > 1 file changed, 22 insertions(+), 8 deletions(-)
Reviewed-by: Matheus Tavares Bernardino <[email protected]> (BTW, apologies for the repeated replies in the second patch. I had a bug in my setting here)
