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) > > > > 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 -- H.J.
