https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108477
Roger Sayle <roger at nextmovesoftware dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
Status|NEW |ASSIGNED
--- Comment #4 from Roger Sayle <roger at nextmovesoftware dot com> ---
If my recently proposed aop_optab patch gets approved, this issue can be solved
using the patch below:
diff --git a/gcc/expr.cc b/gcc/expr.cc
index 0a7013e3a25..4678602ba56 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -10866,8 +10866,17 @@ expand_expr_real_2 (const_sepops ops, rtx target,
machine_mode tmode,
but that is probably not worth while. */
case BIT_AND_EXPR:
+ goto binop;
+
case BIT_IOR_EXPR:
case BIT_XOR_EXPR:
+ if ((get_nonzero_bits (treeop0) & get_nonzero_bits (treeop1)) == 0)
+ {
+ expand_operands (treeop0, treeop1,
+ subtarget, &op0, &op1, EXPAND_NORMAL);
+ this_optab = aop_optab;
+ goto binop3;
+ }
goto binop;
case LROTATE_EXPR:
This implements Jakub's suggestion of get_nonzero_bits at RTL expansion time.
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642255.html
Many thanks to Uros for pointing me to this issue. The aop_optab (and the
ability for backends to specify which operator to use for each mode) was the
missing piece of the puzzle.
