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

Reply via email to