On 7/8/24 13:36, Jeff Law wrote:
On 7/8/24 1:25 PM, Patrick O'Neill wrote:
https://gcc.gnu.org/onlinedocs/gccint/Machine-Independent-Predicates.html
| Function: const_int_operand
| This predicate allows any CONST_INT expression that fits in
mode. It is an appropriate choice for an immediate operand that does
not allow a symbol or label.
If I'm reading this right the const_int mode constrains the const_int
to a given mode.
Not super relevant here since mod_s/mod_f is a 6 state enum but it
looks like const_int is at least aware of the mode?
CONST_INTs simply don't have a mode. So I would be leery of that line
in the documentation.
Is it worth updating the documentation and doing a find-and-replace to
remove all traces of const_int_operand:<mode>? Happy to do the cleanup.
expand pattern insn pattern
operands[1] register -> operands[0] register "=&r"
operands[2] memory -> operands[1] memory "+A"
operands[3] reg_0 -> operands[2] reg_0 "rJ"
operands[4] reg_0 -> operands[3] reg_0 "rJ"
operands[6] const_int -> operands[4] const_int
operands[7] const_int -> operands[5] const_int
Thanks for taking a look - I'll spend some time digging into insn-
recog.cc to get to the bottom of this.
Doing that is a special kind of hell. A few hints :-)
First remove all the #line directives from the generated insn-recog
file, then rebuild just cc1.
If you know the pattern you're trying to match, you can often find it
in the insn-recog* files and work backwards a bit to find a good place
for a breakpoint.
Use a minimal testcase and you can probably put a conditional
breakpoint in the recognizer.
But no matter how you slice it, it's going to be ugly.
Thanks for the tips. Thankfully the failure was early enough that I
could throw an assert on the simode expander and figure it out from the
stack trace.
https://github.com/gcc-mirror/gcc/blob/e611189899bb885a27ef8d17f77c02ada6c69069/gcc/optabs.cc#L7138-L7142
Looks like the behavior is intended to prevent amocas being used as an
atomic load/store:
https://gcc.gnu.org/legacy-ml/gcc-patches/2017-01/msg02344.html
Through this I found that the sync variant is recognized so I'm
unblocked for the TImode expander!:
void sync_compare_exchange_long_long_seq_cst (__int128 *bar, __int128 baz,
__int128 qux)
{
__sync_bool_compare_and_swap(bar, baz, qux);
}
cat test.S
sync_compare_exchange_long_long_seq_cst:
mv a6,a1
mv t1,a3
mv a7,a2
mv t2,a4
amocassupergprTI
Thanks,
Patrick
