[Bug target/109254] Bug in gcc (13.0.1) support for ARM SVE, which randomly modifies the prediction register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109254 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |13.0 --- Comment #9 from Andrew Pinski --- Fixed.
[Bug target/109254] Bug in gcc (13.0.1) support for ARM SVE, which randomly modifies the prediction register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109254 --- Comment #8 from Jakub Jelinek --- Should be fixed on the trunk so far.
[Bug target/109254] Bug in gcc (13.0.1) support for ARM SVE, which randomly modifies the prediction register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109254 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b1f6cb2cc3aad0521ad3181d5107e52be155fd18 commit r13-6965-gb1f6cb2cc3aad0521ad3181d5107e52be155fd18 Author: Jakub Jelinek Date: Sat Apr 1 08:55:55 2023 +0200 aarch64, builtins: Include PR registers in FUNCTION_ARG_REGNO_P etc. [PR109254] The following testcase is miscompiled on aarch64-linux in the regname pass, because while the function takes arguments in the p0 register, FUNCTION_ARG_REGNO_P doesn't reflect that, so DF doesn't know the register is used in register passing. It sees 2 chains with p1 register and wants to replace the second one and as DF doesn't know p0 is live at the start of the function, it will happily use p0 register even when it is used in subsequent instructions. The following patch fixes that. FUNCTION_ARG_REGNO_P returns non-zero for p0-p3 (unconditionally, seems for the floating/vector registers it doesn't conditionalize them on TARGET_FLOAT either, but if you want, I can conditionalize p0-p3 on TARGET_SVE), similarly targetm.calls.function_value_regno_p returns true for p0-p3 registers if TARGET_SVE (again for consistency, that function conditionalizes the float/vector on TARGET_FLOAT). Now, that change broke bootstrap in libobjc and some __builtin_apply_args/__builtin_apply/__builtin_return tests. The aarch64_get_reg_raw_mode hook already documents that SVE scalable arg/return passing is fundamentally incompatible with those builtins, but unlike the floating/vector regs where it forces a fixed vector mode, I think there is no fixed mode which could be used for p0-p3. So, I have tweaked the generic code so that it uses VOIDmode return from that hook to signal that a register shouldn't be touched by __builtin_apply_args/__builtin_apply/__builtin_return despite being mentioned in FUNCTION_ARG_REGNO_P or targetm.calls.function_value_regno_p. gcc/ 2023-04-01 Jakub Jelinek PR target/109254 * builtins.cc (apply_args_size): If targetm.calls.get_raw_arg_mode returns VOIDmode, handle it like if the register isn't used for passing arguments at all. (apply_result_size): If targetm.calls.get_raw_result_mode returns VOIDmode, handle it like if the register isn't used for returning results at all. * target.def (get_raw_result_mode, get_raw_arg_mode): Document what it means to return VOIDmode. * doc/tm.texi: Regenerated. * config/aarch64/aarch64.cc (aarch64_function_value_regno_p): Return TARGET_SVE for P0_REGNUM. (aarch64_function_arg_regno_p): Also return true for p0-p3. (aarch64_get_reg_raw_mode): Return VOIDmode for PR_REGNUM_P regs. gcc/testsuite/ 2023-04-01 Jakub Jelinek Richard Sandiford PR target/109254 * gcc.target/aarch64/sve/pr109254.c: New test.
[Bug target/109254] Bug in gcc (13.0.1) support for ARM SVE, which randomly modifies the prediction register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109254 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-03-27 Status|UNCONFIRMED |NEW --- Comment #6 from Andrew Pinski --- Confirmed.
[Bug target/109254] Bug in gcc (13.0.1) support for ARM SVE, which randomly modifies the prediction register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109254 --- Comment #5 from Jakub Jelinek --- Created attachment 54741 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54741&action=edit gcc13-pr109254.patch Those patches break bootstrap though (in libobjc) and regress some __builtin_apply*/__builtin_return* testcases. Trying this now instead.
[Bug target/109254] Bug in gcc (13.0.1) support for ARM SVE, which randomly modifies the prediction register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109254
--- Comment #4 from Jakub Jelinek ---
And
--- gcc/config/aarch64/aarch64.cc.jj2023-03-13 00:11:52.328213351 +0100
+++ gcc/config/aarch64/aarch64.cc 2023-03-23 16:57:29.957866005 +0100
@@ -7388,6 +7388,9 @@ aarch64_function_value_regno_p (const un
if (regno >= V0_REGNUM && regno < V0_REGNUM + HA_MAX_NUM_FLDS)
return TARGET_FLOAT;
+ if (regno == P0_REGNUM)
+return TARGET_SVE;
+
return false;
}
Or can one actually return in more than p0? Tried struct S { svbool_t a, b; };
but that is rejected...
[Bug target/109254] Bug in gcc (13.0.1) support for ARM SVE, which randomly modifies the prediction register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109254
--- Comment #3 from Jakub Jelinek ---
2023-03-23 Jakub Jelinek
PR target/109254
* config/aarch64/aarch64.cc (aarch64_function_arg_regno_p): Also
return true for p0-p3.
--- gcc/config/aarch64/aarch64.cc.jj2023-03-13 00:11:52.328213351 +0100
+++ gcc/config/aarch64/aarch64.cc 2023-03-23 16:57:29.957866005 +0100
@@ -7959,7 +7959,8 @@ bool
aarch64_function_arg_regno_p (unsigned regno)
{
return ((GP_REGNUM_P (regno) && regno < R0_REGNUM + NUM_ARG_REGS)
- || (FP_REGNUM_P (regno) && regno < V0_REGNUM + NUM_FP_ARG_REGS));
+ || (FP_REGNUM_P (regno) && regno < V0_REGNUM + NUM_FP_ARG_REGS)
+ || (PR_REGNUM_P (regno) && regno < P0_REGNUM + NUM_PR_ARG_REGS));
}
/* Implement FUNCTION_ARG_BOUNDARY. Every parameter gets at least
fixes this. Or do we want to return true for p0-p3 only if SVE is enabled?
Not familiar with SVE enough to turn the testcase into gcc.target/aarch64/sve
runtime tests (bet we need __attribute__((noipa)) on the function, but unsure
how to initialize the arguments in the caller and how to verify the result is
correct in it after the call.
[Bug target/109254] Bug in gcc (13.0.1) support for ARM SVE, which randomly modifies the prediction register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109254 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Yeah, before rnreg pass the fcmlt has p1 as destination and fsub/fsel use p0 (i.e. the parameter) while sel in between them uses p1. I see this behavior already in r10-5107-gb789efeae8c0620b8 and shortly before that it has been rejected with "variable-sized object may not be initialized" errors.
[Bug target/109254] Bug in gcc (13.0.1) support for ARM SVE, which randomly modifies the prediction register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109254 --- Comment #1 from Andrew Pinski --- -fno-rename-registers is the workaround
