On 7/13/2026 7:20 AM, Nathan Sidwell wrote:
Slim RTL dumps show unspec numbers as decimal numbers. These are (a)
meaningless and (b) if you manage to remember any of them, they're not
stable against some random md file in your target changing the
enumerations.
1) This patch emits the UNSPEC or UNSPECV name. I strip the leading
UNSPEC_?, leaving FOO or V_FOO depending. And also elide the space
that prefixed it -- no loss of readability, the previous char is ']'
So instead of:
unspec/v[r176,0xc] 365
one gets:
unspec/v[r176,0xc]V_SFPCONFIG
which means a lot more (to me at least).
An additional problem is also addressed in both slim and regular rtl
printers. For unspec_volatile they fall back to printing the UNSPEC
enum, if the value is out of range. But this is wrong. If there are
*any* UNSPECV values, *all* unspec_volatiles should use them. There's
no guarantee that the UNSPEC value one might have intended doesn't
match an UNSPECV value from some (other) md file in your target. (As I
found out and addressed with a recent patch concerning Risc-V
atomics.) Thus this patch only does the fallback if there are no
UNSPECV values.
ok?
Not a fan of the conditional compilation introduced here. But I'll get
over it. OK.
jeff
