Question about fold C_MAYBE_CONST_EXPR expressions

[Bin.Cheng]

Hi,
I ran into a problem that C frontend (in function
build_conditional_expr) creates expression like (C_MAYBE_CONST_EXPR
(NULL, x + const)).  The inner expression (and its operands) have
unsigned int type.  After that, the expression needs to be casted to
result type which is unsigned short.  In this case,
convert_to_integer/convert_to_integer_1 doesn't fold into
C_MAYBE_CONST_EXPR and just returns (unsigned
short)(C_MAYBE_CONST_EXPR (NULL, x + const)), as a result, (unsigned
short)(x + const) won't be simplified as (unsigned short)x + const.
My questions are, 1) Is it possible to fold type conversion into
C_MAYBE_CONST_EXPR's inner expression in convert_to_integer_1?  2) If
not, looks like there are couple of places the mentioned fold can be
done, for example, after stripping C_MAYBE_CONST_EXPR and before (or
during) gimplify.  So which place is preferred?

Thanks,
bin

Re: Question about fold C_MAYBE_CONST_EXPR expressions

[Prathamesh Kulkarni]

On 24 July 2016 at 21:26, Bin.Cheng  wrote:
> Hi,
> I ran into a problem that C frontend (in function
> build_conditional_expr) creates expression like (C_MAYBE_CONST_EXPR
> (NULL, x + const)).  The inner expression (and its operands) have
> unsigned int type.  After that, the expression needs to be casted to
> result type which is unsigned short.  In this case,
> convert_to_integer/convert_to_integer_1 doesn't fold into
> C_MAYBE_CONST_EXPR and just returns (unsigned
> short)(C_MAYBE_CONST_EXPR (NULL, x + const)), as a result, (unsigned
> short)(x + const) won't be simplified as (unsigned short)x + const.
> My questions are, 1) Is it possible to fold type conversion into
> C_MAYBE_CONST_EXPR's inner expression in convert_to_integer_1?  2) If
> not, looks like there are couple of places the mentioned fold can be
> done, for example, after stripping C_MAYBE_CONST_EXPR and before (or
> during) gimplify.  So which place is preferred?
Sorry, I have a very silly question:
I don't understand how the following transform
(unsigned short) (x + const) to (unsigned short)x + const would be legal
since the operands to PLUS_EXPR in latter case would have different types
(unsigned short, unsigned) ?
I suppose in GIMPLE (and GENERIC too?)
we require rhs1 and rhs2 to have same types  ?

Thanks,
Prathamesh
>
> Thanks,
> bin

gcc-7-20160724 is now available

[gccadmin]

Snapshot gcc-7-20160724 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/7-20160724/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 238695

You'll find:

 gcc-7-20160724.tar.bz2   Complete GCC

  MD5=7accfa4d0138116f49236ebd16e667cb
  SHA1=db165edc29929ef14d28a7c17a94c700ddfb9a39

Diffs from 7-20160717 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-7
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

possibly dead call from slsr_process_phi () to gimple_bb ()

[Prathamesh Kulkarni]

Hi,
I am trying to write a WIP patch to warn for dead function calls,
and incidentally it caught the following dead call to gimple_bb() from
slsr_process_phi () in gimple-ssa-strength-reduction.c:

 if (SSA_NAME_IS_DEFAULT_DEF (arg))
   arg_bb = single_succ (ENTRY_BLOCK_PTR_FOR_FN (cfun));
 else
   gimple_bb (SSA_NAME_DEF_STMT (arg));

Presumably it should be:
arg_bb = gimple_bb (SSA_NAME_DEF_STMT (arg)) ?

Thanks,
Prathamesh