As noticed by Jakub in the discussion about yesterday's bswap changes.
The change should be a no-op in practice since AND and XOR don't have
libgcc2 functions; we'd always split into word-mode operations instead.
Even so, it doesn't make conceptual sense for can_open_code_p to call
can_implement_p.
The fact that this seems to be a recurring blind spot for me suggests
that I didn't choose good names...
Tested on aarch64-linux-gnu, powerpc64le-linux-gnu and
x86_64-linux-gnu. Pushed as obvious.
Richard
gcc/
* optabs-query.cc (can_open_code_p): Use can_open_code_p rather
than can_implement_p when testing for AND and XOR.
---
gcc/optabs-query.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/optabs-query.cc b/gcc/optabs-query.cc
index 8226356c7d4..58842e40ed6 100644
--- a/gcc/optabs-query.cc
+++ b/gcc/optabs-query.cc
@@ -837,7 +837,7 @@ can_open_code_p (optab op, machine_mode mode)
if ((op == neg_optab || op == abs_optab)
&& is_a<scalar_float_mode> (GET_MODE_INNER (mode), &fmode)
&& get_absneg_bit_mode (op, mode, fmode, &bitpos).exists (&new_mode)
- && can_implement_p (op == neg_optab ? xor_optab : and_optab, new_mode))
+ && can_open_code_p (op == neg_optab ? xor_optab : and_optab, new_mode))
return true;
scalar_int_mode int_mode;
--
2.54.0
