Thanks, Andrew. I also implemented a quick patch on our port (based on GCC 4.5). I noticed it produced better code now for our applications. Maybe eliminating control flow in earlier stage helps other optimizing passes. Currently, tree if-conversion pass is not turned on by default (only with tree vectorization or some other passes). Maybe it is worth to make it default at -O2 (for those processors support conditional move)?
Cheers, Bingfeng > -----Original Message----- > From: Andrew Pinski [mailto:pins...@gmail.com] > Sent: 24 October 2011 17:20 > To: Richard Guenther > Cc: Bingfeng Mei; gcc@gcc.gnu.org > Subject: Re: Why doesn't GCC generate conditional move for COND_EXPR? > > On Mon, Oct 24, 2011 at 7:00 AM, Richard Guenther > <richard.guent...@gmail.com> wrote: > > On Mon, Oct 24, 2011 at 2:55 PM, Bingfeng Mei <b...@broadcom.com> > wrote: > >> Hello, > >> I noticed that COND_EXPR is not expanded to conditional move > >> as MIN_EXPR/MAX_EXPR are (assuming movmodecc is available). > >> I wonder why not? > >> > >> I have some loop that fails tree vectorization, but still contains > >> COND_EXPR from tree ifcvt pass. In the end, the generated code > >> is worse than if I don't turned -ftree-vectorize on. This > >> is on our private port. > > > > Because nobody touched COND_EXPR expansion since ages. > > I have a patch which I will be submitting next week or so that does > this expansion correctly. In fact I have a few patches which improves > the generation of COND_EXPR in simple cases (in PHI-OPT). > > Thanks, > Andrew Pinski
