This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] New predicate covering NOP_EXPR and CONVERT_EXPR
- From: Richard Guenther <rguenther at suse dot de>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gcc-patches at gcc dot gnu dot org, java-patches at gcc dot gnu dot org
- Date: Fri, 2 Dec 2005 10:54:10 +0100 (CET)
- Subject: Re: [PATCH] New predicate covering NOP_EXPR and CONVERT_EXPR
- References: <Pine.LNX.4.44.0512012025120.4574-100000@www.eyesopen.com>
On Thu, 1 Dec 2005, Roger Sayle wrote:
>
> Hi Richard,
>
> On Thu, 1 Dec 2005, Richard Guenther wrote:
> > For unifying handling of NOP_EXPR and CONVERT_EXPR and possibly getting
> > rid of either of these, this adds a new predicate covering now both
> > and in future the remaining one.
>
> I believe there's a better way to reach that goal, with less churn
> to the source code. Back in 4.1's stage1 timeframe I investigated
> the following line of investigation:
[...]
> What do you think? Clearly I've given this some thought :)
Yes, I think this plan is reasonable, and the patch should be
easy to reproduce. I also agree on the frontend specific tree
code for java, if it turns out to be necessary. And most nice
would be to kill NON_LVALUE_EXPR at the same time, too ;)
> I think the fold -> foldN -> fold_buildN transition worked well
> for gcc 4.1.
Which isn't complete...
gcc> grep 'build (' *.c */*.c | wc -l
226
gcc> grep 'fold (build[123]' *.c */*.c | wc -l
51
Thanks for the feedback,
Richard.