Hi Botcazou,
Just notice that this patch may result in some ICE when build libc++ for the
riscv port, details as below.
Please note not all configuration can reproduce this issue, feel free to ping
me if you cannot reproduce this issue. CC more riscv port people for awareness.
during GIMPLE pass: slp
In file included from
/home/box/panli/gnu-toolchain/gcc/libstdc++-v3/src/c++17/floating_to_chars.cc:124:
/home/box/panli/gnu-toolchain/gcc/libstdc++-v3/src/c++17/ryu/generic_128.c: In
function 'int
{anonymous}::ryu::generic128::generic_to_chars(floating_decimal_128, char*)':
/home/box/panli/gnu-toolchain/gcc/libstdc++-v3/src/c++17/ryu/generic_128.c:251:5:
internal compiler error: in require, at machmode.h:313
251 | int generic_to_chars(const struct floating_decimal_128 v, char* const
result) {
| ^~~~~~~~~~~~~~~~
0x30d526b diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
???:0
0x30d637e internal_error(char const*, ...)
???:0
0xdd9c9d fancy_abort(char const*, int, char const*)
???:0
0xbb4f9f can_mult_highpart_p(machine_mode, bool) [clone .cold]
???:0
0x17384b3 default_preferred_div_as_shifts_over_mult(tree_node const*)
???:0
0x2b34967 vect_recog_divmod_pattern(vec_info*, _stmt_vec_info*, tree_node**)
???:0
0x2b2f106 vect_pattern_recog_1(vec_info*, vect_recog_func*, _stmt_vec_info*)
???:0
0x2b2f3b1 vect_pattern_recog(vec_info*)
???:0
0x1a5e403 vect_slp_region(vec<basic_block_def*, va_heap, vl_ptr>,
vec<data_reference*, va_heap, vl_ptr>, vec<int, va_heap, vl_ptr>*, unsigned
int, loop*)
???:0
0x1a60505 vect_slp_bbs(vec<basic_block_def*, va_heap, vl_ptr> const&, loop*)
???:0
0x1a608f3 vect_slp_function(function*)
???:0
0x1a6c2a1 (anonymous namespace)::pass_slp_vectorize::execute(function*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
Pan
-----Original Message-----
From: Eric Botcazou <botca...@adacore.com>
Sent: Tuesday, April 30, 2024 12:11 AM
To: gcc-patches@gcc.gnu.org
Subject: [PATCH] Add widening expansion of MULT_HIGHPART_EXPR for integral modes
Hi,
for integral modes, the expansion of MULT_HIGHPART_EXPR requires the presence
of an {s,u}mul_highpart optab whereas, for vector modes, widening expansion is
supported. This adds a widening expansion for integral modes too, which is in
fact already implemented in expmed_mult_highpart_optab. We'll use that in a
subsequent change to the Ada front-end to generate fast modulo reduction for
modular types with nonbinary modulus (a little controversial Ada 95 feature).
Tested on x86-64/Linux, OK for the mainline?
2024-04-29 Eric Botcazou <ebotca...@adacore.com>
* expmed.h (expmed_mult_highpart_optab): Declare.
* expmed.cc (expmed_mult_highpart_optab): Remove static keyword.
Do not assume that OP1 is a constant integer. Fix pasto.
(expmed_mult_highpart): Pass OP1 narrowed to MODE in all the calls
to expmed_mult_highpart_optab.
* optabs-query.cc (can_mult_highpart_p): Use 2 for integer widening
and shift subsequent values accordingly.
* optabs.cc (expand_mult_highpart): Call expmed_mult_highpart_optab
when can_mult_highpart_p returns 2 and adjust to above change.
--
Eric Botcazou
