This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Question about fold C_MAYBE_CONST_EXPR expressions
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Bin.Cheng <amker dot cheng at gmail dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 25 Jul 2016 17:00:29 +0000
- Subject: Re: Question about fold C_MAYBE_CONST_EXPR expressions
- Authentication-results: sourceware.org; auth=none
- References: <CAHFci28_maioG0kc+0LAtovhMPKkPVhz6z7KZqo7OxscTDvrYg@mail.gmail.com>
On Sun, 24 Jul 2016, 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?
The folding should occur from, or after, c_fully_fold. In general,
convert_to_* should do less optimization; the optimizations there should
be moved to the match-and-simplify infrastructure.
--
Joseph S. Myers
joseph@codesourcery.com