Hi,
On 11/27/25 09:45, Lulu Cheng wrote:
I'm sorry for the delay in responding. Thank you very much for your
modifications.
After our discussion, we have determined that the implementation of
__builtin_trap
can be finalized (including for LA32) using the instruction "amswap.w
$r0, $r1, $r0"
(as described in section 1.1.1 of document [1]:
"LA64 applications are 'application-level backward binary
compatibility' with LA32 applications."
This indicates that the implementation behavior of LA32 instructions
is consistent with LA64,
so the instruction encoding of "amswap.w $r0, $r1, $r0" can also be
used to achieve the
behavior of an undefined instruction.)
My point is not about LA32 compatibility at all, because as you said, an
LA32 implementation either doesn't have AMO thus amswap.w is going to
INE anyways, or it has AMO and the special amswap.w instruction INEs as
specified.
My point is that we should not constrain ourselves with the integer
argument which is less expressive, and counter-intuitive naming (why
name it "break code" when "break code -1" means something not a
"break"?). We cannot say for sure that another way of trapping will
never get added to LoongArch again, and I don't think it's acceptable
from a user experience standpoint to make say "break code -2048 to
-1024" means "ud blah" with a mapping between the numeric value and the
intended "ud" immediate...
Additionally, we will validate the value of "-mbreak-code=". If the
value is not between 0 and
32767 and is not -1, an error will be reported.
Thanks!
[1]:https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.pdf
Based on my point above, even if we reserve space for extension in the
integer parameter space, the UX still would be horrible in case we
support another way to trap. I'd like to repeat myself, that I don't
think "amswap INE" and "break" will be the only two ways to trap under
LoongArch ever, so please reconsider.
