On Wed, Nov 13, 2024 at 8:29 AM H.J. Lu <hjl.to...@gmail.com> wrote: > > On Wed, Nov 13, 2024 at 5:57 AM H.J. Lu <hjl.to...@gmail.com> wrote: > > > > On Tue, Nov 12, 2024 at 9:30 PM Richard Biener > > <richard.guent...@gmail.com> wrote: > > > > > > On Tue, Nov 12, 2024 at 1:49 PM H.J. Lu <hjl.to...@gmail.com> wrote: > > > > > > > > When passing 0xff as an unsigned char function argument, the C frontend > > > > promotion will promote it to int: > > > > > > > > <integer_cst 0x7fffe6aa23a8 type <integer_type 0x7fffe98225e8 int> > > > > constant 255> > > > > > > > > and expand_normal always returns the rtx value using the sign-extended > > > > representation, > > > > > > > > (const_int 255 [0xff]) > > > > > > > > If the C frontend doesn't promote unsigned char to int, expand_normal > > > > will > > > > get > > > > > > > > <integer_cst 0x7fffe9824018 type <integer_type 0x7fffe9822348 unsigned > > > > char > co > > > > nstant 255> > > > > > > > > and return > > > > > > > > (const_int -1 [0xffffffffffffffff]) > > > > > > that looks wrong to me, but in other places we ensure > > > to use trunc_int_for_mode (), not some odd function like > > > you introduce here? > > > > I opened: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117547 > > > > Here is the v2 patch with reference to PR target/117547. > > When passing 0xff as an unsigned char function argument with the C frontend > promotion, expand_normal gets > > <integer_cst 0x7fffe6aa23a8 type <integer_type 0x7fffe98225e8 int> constant > 255> > > and returns the rtx value using the sign-extended representation: > > (const_int 255 [0xff]) > > Without the C frontend promotion, expand_normal gets > > <integer_cst 0x7fffe9824018 type <integer_type 0x7fffe9822348 unsigned char > > co > nstant 255> > > and returns > > (const_int -1 [0xffffffffffffffff]) > > which doesn't work with the IN_RANGE predicates. Extract the 8-bit/16-bit > integer constants to always return > > (const_int 255 [0xff]) > > so that the return value can be used with the IN_RANGE predicates, like > const_0_to_255_operand, without the C frontend promotion. + if (TREE_CODE (arg) == INTEGER_CST) + { + tree type = TREE_TYPE (arg); + if (INTEGRAL_TYPE_P (type) + && TYPE_PRECISION (type) < TYPE_PRECISION (integer_type_node)) + { + HOST_WIDE_INT cst = TREE_INT_CST_LOW (arg); + return GEN_INT (cst); + } + } +
Shouldn't we guard this with TYPE_UNSIGNED (type)? I'm also worried that GEN_INT may trigger ICE like PR96262. Can we use gen_int_mode instead, or we must use GEN_INT here? > > PR target/117547 > * config/i386/i386-expand.cc (ix86_expand_integer_cst_argument): > New function. > (ix86_expand_args_builtin): Call ix86_expand_integer_cst_argument > to expand the argument before calling fixup_modeless_constant. > (ix86_expand_round_builtin): Likewise. > (ix86_expand_special_args_builtin): Likewise. > (ix86_expand_builtin): Likewise. > > -- > H.J. -- BR, Hongtao
