[Bug rtl-optimization/114766] ^ constraint modifier unexpectedly affects register class selection.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114766 --- Comment #3 from Vladimir Makarov --- (In reply to Tamar Christina from comment #2) > (In reply to Vladimir Makarov from comment #1) > > (In reply to Tamar Christina from comment #0) > > > The documentation for ^ states: > > > > If it works for you, we could try to use the patch (although it needs some > > investigation how other targets uses the hint). In any case, the > > documentation should be modified or made more clear depending on applying or > > not applying the patch. > > Yeah, using the patch gives us the behavior we expected, we added a > workaround for now so we can investigate what other targets do in GCC 15. > > But while looking at this we also got some unexpected behavior with using ? > > > r103 costs: W8_W11_REGS:2000 W12_W15_REGS:2000 TAILCALL_ADDR_REGS:2000 > STUB_REGS:2000 GENERAL_REGS:2000 FP_LO8_REGS:0 FP_LO_REGS:0 FP_REGS:0 > POINTER_AND_FP_REGS:7000 MEM:9000 > > In this particular pattern the ? isn't needed so we're removing it, but the > behavior is still unexpected. '?' is a very old hint (unlike ^ and @). It is used by all targets for many years. IRA cost calculation uses exactly the same algorithm as it was in now non-existing regclass.c file. Changing code related to processing '?' would have very unpredictable consequences for many targets. After many years working on RA, I am still surprised how fragile code calculating costs and reg classes and how insignificant changes can result in a cascade of GCC test failures. There are many factors which still can result in zero cost code even when '?' is used. You can try to use more one '?' and see what happens. If the cost is still zero, I could look what is going on in the cost calculation.
[Bug rtl-optimization/114766] ^ constraint modifier unexpectedly affects register class selection.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114766
--- Comment #2 from Tamar Christina ---
(In reply to Vladimir Makarov from comment #1)
> (In reply to Tamar Christina from comment #0)
> > The documentation for ^ states:
>
> If it works for you, we could try to use the patch (although it needs some
> investigation how other targets uses the hint). In any case, the
> documentation should be modified or made more clear depending on applying or
> not applying the patch.
Yeah, using the patch gives us the behavior we expected, we added a workaround
for now so we can investigate what other targets do in GCC 15.
But while looking at this we also got some unexpected behavior with using ?
For instance we have the pattern:
;; Equal width integer to fp conversion.
(define_insn "2"
[(set (match_operand:GPF 0 "register_operand")
(FLOATUORS:GPF (match_operand: 1 "register_operand")))]
"TARGET_FLOAT"
{@ [ cons: =0 , 1 ; attrs: type , arch ]
[ w, w ; neon_int_to_fp_ , simd ]
cvtf\t%0, %1
[ w, ?r ; f_cvti2f, fp]
cvtf\t%0, %1
})
for modeling floating point conversions. We had expected ? to make the
alternative more expensive, but still possible. However again during IRA the
entire register class is blocked:
r103: preferred FP_REGS, alternative NO_REGS, allocno FP_REGS
I would have expected that the additional penalty should never make an
alternative impossible.
We thought maybe the move costs were an issue, but we tried with various big
and small numbers but it looks like the move costs have little to no effect.
Since the original value in this case was in r:
Choosing alt 0 in insn 7: (0) =rk (1) %rk (2) I {*adddi3_aarch64}
I would have expected the cost for FP_REGS not to be 0, as there's a register
file move involved:
r103 costs: W8_W11_REGS:2000 W12_W15_REGS:2000 TAILCALL_ADDR_REGS:2000
STUB_REGS:2000 GENERAL_REGS:2000 FP_LO8_REGS:0 FP_LO_REGS:0 FP_REGS:0
POINTER_AND_FP_REGS:7000 MEM:9000
In this particular pattern the ? isn't needed so we're removing it, but the
behavior is still unexpected.
[Bug rtl-optimization/114766] ^ constraint modifier unexpectedly affects register class selection.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114766 --- Comment #1 from Vladimir Makarov --- (In reply to Tamar Christina from comment #0) > The documentation for ^ states: > > "This constraint is analogous to ‘?’ but it disparages slightly the > alternative only if the operand with the ‘^’ needs a reload." > > > The penalty here seems incorrect, and removing it seems to get the > constraint to work properly. > So the question is, is it a bug, or are we using it incorrectly? or a > documentation bug? The current behavior of '^' is how it was originally planned. With this point of view I would say that it is a documentation ambiguity. documentation of '?' also does not clearly say about its affect on the cost calculation and as a consequence on choosing register class. On the other hand, I don't know what is really needed. If you need what you expected, please try the following patch: diff --git a/gcc/ira-costs.cc b/gcc/ira-costs.cc index c86c5a16563..04d2f21b023 100644 --- a/gcc/ira-costs.cc +++ b/gcc/ira-costs.cc @@ -771,10 +771,6 @@ record_reg_classes (int n_alts, int n_ops, rtx *ops, c = *++p; break; - case '^': - alt_cost += 2; - break; - case '?': alt_cost += 2; break; If it works for you, we could try to use the patch (although it needs some investigation how other targets uses the hint). In any case, the documentation should be modified or made more clear depending on applying or not applying the patch.
