On Wed, Nov 13, 2024 at 6:22 AM H.J. Lu <hjl.to...@gmail.com> wrote: > > On Wed, Nov 13, 2024 at 11:25 AM H.J. Lu <hjl.to...@gmail.com> wrote: > > > > On Wed, Nov 13, 2024 at 10:23 AM Hongtao Liu <crazy...@gmail.com> wrote: > > > > > > 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)? > > > > Good idea. I will add it. > > > > > 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? > > > > gen_int_mode (255, QImode) returns > > > > (const_int -1 [0xffffffffffffffff]) > > > > unless we use gen_int_mode (255, SImode) > > > > Here is the v3 patch which adds the check with TYPE_UNSIGNED (type). > > OK for master?
While I'm far from an expert here this doesn't look right and instead the const_0_to_255_operand looks bogus to me in not properly taking into account 'mode'. Richard. > H.J. > --- > 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 unsigned > char/short 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. > > 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.
