* [Bug rtl-optimization/114044] ICE: in expand_fn_using_insn, at internal-fn.cc:208 with _BitInt() and -O -fno-tree-dce
2024-02-22 7:01 [Bug rtl-optimization/114044] New: ICE: in expand_fn_using_insn, at internal-fn.cc:208 with _BitInt() and -O -fno-tree-dce zsojka at seznam dot cz
2024-02-22 7:24 ` [Bug rtl-optimization/114044] " pinskia at gcc dot gnu.org
2024-02-22 12:06 ` rguenth at gcc dot gnu.org
@ 2024-02-22 17:07 ` jakub at gcc dot gnu.org
2024-02-26 15:24 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-02-22 17:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114044
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Smaller testcase:
void
foo (void)
{
unsigned _BitInt(256) a = 3;
__builtin_clzg (a);
}
The thing is that in this testcase bitint lowering doesn't even know it should
do anything.
The whole behavior of the pass is keyed on there being any SSA_NAMEs for
middle/large/huge BITINT_TYPE with some extra exceptions (it looks at virtual
SSA_NAMEs to see if there isn't a memory store of a middle+ _BitInt INTEGER_CST
and for scalar floating point SSA_NAMEs if they aren't computed from conversion
from middle+ _BitInt INTEGER_CSTs), and even if the pass for some other reason
triggers in the function,
it will not look at statements which don't have any large+ _BitInt SSA_NAMEs,
or are large+ _BitInt INTEGER_CST store or FLOAT_EXPR from large+ _BitInt
INTEGER_CST or the overflow ifns with _Complex large+ _BitInt result.
We really don't want to lower those ifns like
.CLZ/.CTZ/.CLRSB/.POPCOUNT/.PARITY/.FFS
with INTEGER_CST operands, or after all even say .ADD_OVERFLOW (0, 1) where
just operands are large/huge _BitInt but say _Complex int result, those are all
expected to be folded instead.
Now, if s/^void/int;s/__builtin/return &/' above, we fold it in
gimple_fold_stmt_to_constant_1:
#0 wi::clz (x=...) at ../../gcc/wide-int.cc:2164
#1 0x00000000008a9d9b in fold_const_call_ss (result=0x7fffffffc4e0,
fn=CFN_CLZ, arg=..., precision=32, arg_type=<bitint_type 0x7fffea2db5e8>) at
../../gcc/fold-const-call.cc:1029
#2 0x00000000008aa9a5 in fold_const_call_1 (fn=CFN_CLZ, type=<integer_type
0x7fffea14c5e8 int>, arg=<integer_cst 0x7fffea2e5c18>) at
../../gcc/fold-const-call.cc:1254
#3 0x00000000008ab4d6 in fold_const_call (fn=CFN_CLZ, type=<integer_type
0x7fffea14c5e8 int>, arg=<integer_cst 0x7fffea2e5c18>) at
../../gcc/fold-const-call.cc:1385
#4 0x000000000189d6e0 in gimple_resimplify1 (seq=0x0, res_op=0x7fffffffc980,
valueize=0xf42f7d <valueize_op_1(tree)>) at
../../gcc/gimple-match-exports.cc:925
#5 0x000000000189b419 in gimple_match_op::resimplify (this=0x7fffffffc980,
seq=0x0, valueize=0xf42f7d <valueize_op_1(tree)>) at
../../gcc/gimple-match-exports.cc:111
#6 0x000000000189d5b3 in gimple_simplify (stmt=<gimple_call 0x7fffea13aea0>,
res_op=0x7fffffffc980, seq=0x0, valueize=0xf42f7d <valueize_op_1(tree)>,
top_valueize=0xf42f41 <valueize_op(tree)>) at
../../gcc/gimple-match-exports.cc:898
#7 0x000000000090986a in gimple_fold_stmt_to_constant_1 (stmt=<gimple_call
0x7fffea13aea0>, valueize=0xf42f41 <valueize_op(tree)>, gvalueize=0xf42f7d
<valueize_op_1(tree)>)
at ../../gcc/gimple-fold.cc:7551
#8 0x0000000000f4308a in ccp_fold (stmt=<gimple_call 0x7fffea13aea0>) at
../../gcc/tree-ssa-ccp.cc:1290
#9 0x0000000000f48d1b in evaluate_stmt (stmt=<gimple_call 0x7fffea13aea0>) at
../../gcc/tree-ssa-ccp.cc:2228
or with extra -fno-tree-ccp in:
#0 wi::clz (x=...) at ../../gcc/wide-int.cc:2164
#1 0x00000000008a9d9b in fold_const_call_ss (result=0x7fffffffceb0,
fn=CFN_CLZ, arg=..., precision=32, arg_type=<bitint_type 0x7fffea2db5e8>) at
../../gcc/fold-const-call.cc:1029
#2 0x00000000008aa9a5 in fold_const_call_1 (fn=CFN_CLZ, type=<integer_type
0x7fffea14c5e8 int>, arg=<integer_cst 0x7fffea2e5c18>) at
../../gcc/fold-const-call.cc:1254
#3 0x00000000008ab4d6 in fold_const_call (fn=CFN_CLZ, type=<integer_type
0x7fffea14c5e8 int>, arg=<integer_cst 0x7fffea2e5c18>) at
../../gcc/fold-const-call.cc:1385
#4 0x000000000189d6e0 in gimple_resimplify1 (seq=0x7fffffffd278,
res_op=0x7fffffffd200, valueize=0xf811c3 <fwprop_ssa_val(tree)>) at
../../gcc/gimple-match-exports.cc:925
#5 0x000000000189b419 in gimple_match_op::resimplify (this=0x7fffffffd200,
seq=0x7fffffffd278, valueize=0xf811c3 <fwprop_ssa_val(tree)>) at
../../gcc/gimple-match-exports.cc:111
#6 0x000000000189d5b3 in gimple_simplify (stmt=<gimple_call 0x7fffea13ae10>,
res_op=0x7fffffffd200, seq=0x7fffffffd278, valueize=0xf811c3
<fwprop_ssa_val(tree)>,
top_valueize=0xf811c3 <fwprop_ssa_val(tree)>) at
../../gcc/gimple-match-exports.cc:898
#7 0x00000000009060dd in fold_stmt_1 (gsi=0x7fffffffd630, inplace=false,
valueize=0xf811c3 <fwprop_ssa_val(tree)>) at ../../gcc/gimple-fold.cc:6359
#8 0x0000000000906833 in fold_stmt (gsi=0x7fffffffd630, valueize=0xf811c3
<fwprop_ssa_val(tree)>) at ../../gcc/gimple-fold.cc:6525
or with extra -fno-tree-ccp -fno-tree-forwprop in:
#0 wi::clz (x=...) at ../../gcc/wide-int.cc:2164
#1 0x00000000008a9d9b in fold_const_call_ss (result=0x7fffffffcd50,
fn=CFN_CLZ, arg=..., precision=32, arg_type=<bitint_type 0x7fffea2db5e8>) at
../../gcc/fold-const-call.cc:1029
#2 0x00000000008aa9a5 in fold_const_call_1 (fn=CFN_CLZ, type=<integer_type
0x7fffea14c5e8 int>, arg=<integer_cst 0x7fffea2e5c18>) at
../../gcc/fold-const-call.cc:1254
#3 0x00000000008ab4d6 in fold_const_call (fn=CFN_CLZ, type=<integer_type
0x7fffea14c5e8 int>, arg=<integer_cst 0x7fffea2e5c18>) at
../../gcc/fold-const-call.cc:1385
#4 0x000000000189d6e0 in gimple_resimplify1 (seq=0x0, res_op=0x7fffffffd1f0,
valueize=0x906784 <no_follow_ssa_edges(tree_node*)>) at
../../gcc/gimple-match-exports.cc:925
#5 0x000000000189b419 in gimple_match_op::resimplify (this=0x7fffffffd1f0,
seq=0x0, valueize=0x906784 <no_follow_ssa_edges(tree_node*)>) at
../../gcc/gimple-match-exports.cc:111
#6 0x000000000189d5b3 in gimple_simplify (stmt=<gimple_call 0x7fffea13ae10>,
res_op=0x7fffffffd1f0, seq=0x0, valueize=0x906784
<no_follow_ssa_edges(tree_node*)>,
top_valueize=0x106aeba <rpo_vn_valueize(tree_node*)>) at
../../gcc/gimple-match-exports.cc:898
#7 0x000000000090986a in gimple_fold_stmt_to_constant_1 (stmt=<gimple_call
0x7fffea13ae10>, valueize=0x106aeba <rpo_vn_valueize(tree_node*)>,
gvalueize=0x906784 <no_follow_ssa_edges(tree_node*)>) at
../../gcc/gimple-fold.cc:7551
#8 0x000000000106502d in visit_stmt (stmt=<gimple_call 0x7fffea13ae10>,
backedges_varying_p=false) at ../../gcc/tree-ssa-sccvn.cc:6419
etc.
But somehow none of that triggers if the internal fn doesn't have lhs, we just
rely on DCE and DCE can be disabled.
Dunno, shall we just ignore those during expansion if they don't have lhs?
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug rtl-optimization/114044] ICE: in expand_fn_using_insn, at internal-fn.cc:208 with _BitInt() and -O -fno-tree-dce
2024-02-22 7:01 [Bug rtl-optimization/114044] New: ICE: in expand_fn_using_insn, at internal-fn.cc:208 with _BitInt() and -O -fno-tree-dce zsojka at seznam dot cz
` (3 preceding siblings ...)
2024-02-26 15:24 ` jakub at gcc dot gnu.org
@ 2024-02-27 8:55 ` cvs-commit at gcc dot gnu.org
2024-02-27 9:04 ` jakub at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-02-27 8:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114044
--- Comment #5 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:c3c44c01d20b00ab5228f32596153b7f4cbc6036
commit r14-9192-gc3c44c01d20b00ab5228f32596153b7f4cbc6036
Author: Jakub Jelinek <jakub@redhat.com>
Date: Tue Feb 27 09:52:07 2024 +0100
expand: Add trivial folding for bit query builtins at expansion time
[PR114044]
While it seems a lot of places in various optimization passes fold
bit query internal functions with INTEGER_CST arguments to INTEGER_CST
when there is a lhs, when lhs is missing, all the removals of such dead
stmts are guarded with -ftree-dce, so with -fno-tree-dce those unfolded
ifn calls remain in the IL until expansion. If they have large/huge
BITINT_TYPE arguments, there is no BLKmode optab and so expansion ICEs,
and bitint lowering doesn't touch such calls because it doesn't know they
need touching, functions only containing those will not even be further
processed by the pass because there are no non-small BITINT_TYPE SSA_NAMEs
+ the 2 exceptions (stores of BITINT_TYPE INTEGER_CSTs and conversions
from BITINT_TYPE INTEGER_CSTs to floating point SSA_NAMEs) and when walking
there is no special case for calls with BITINT_TYPE INTEGER_CSTs either,
those are for normal calls normally handled at expansion time.
So, the following patch adjust the expansion of these 6 ifns, by doing
nothing if there is no lhs, and also just in case and user disabled all
possible passes that would fold this handles the case of setting lhs
to ifn call with INTEGER_CST argument.
2024-02-27 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/114044
* internal-fn.def (CLRSB, CLZ, CTZ, FFS, PARITY): Use
DEF_INTERNAL_INT_EXT_FN macro rather than DEF_INTERNAL_INT_FN.
* internal-fn.h (expand_CLRSB, expand_CLZ, expand_CTZ, expand_FFS,
expand_PARITY): Declare.
* internal-fn.cc (expand_bitquery, expand_CLRSB, expand_CLZ,
expand_CTZ, expand_FFS, expand_PARITY): New functions.
(expand_POPCOUNT): Use expand_bitquery.
* gcc.dg/bitint-95.c: New test.
^ permalink raw reply [flat|nested] 7+ messages in thread