On 7/9/24 12:30 PM, Patrick O'Neill wrote:
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.
It may be the case that specifying the mode keeps the warnings in gen*
happy. There's cases where those generators will complain for modeless
nodes.
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!:
That's good. I very vaguely remember that thread, but I left it to
Torvald to settle (he was our team's expert on memory models, P&C issues
and the like).
Jeff
