RE: [PATCH 1/n] Add conditional compare support

["Zhenqiang Chen" <zhenqiang dot chen at arm dot com>]

> -----Original Message-----
> From: Richard Biener [mailto:richard.guenther@gmail.com]
> Sent: Tuesday, August 27, 2013 8:18 PM
> To: Richard Earnshaw
> Cc: Zhenqiang Chen; GCC Patches
> Subject: Re: [PATCH 1/n] Add conditional compare support
> 
> On Tue, Aug 27, 2013 at 1:56 PM, Richard Earnshaw <rearnsha@arm.com>
> wrote:
> > On 27/08/13 12:10, Richard Biener wrote:
> >> What's this for and what's the desired semantics? I don't like having
> >> extra tree codes for this.  Is this for a specific instruction set
> >> feature?
> >
> > The background is to support the conditional compare instructions in
> > ARM (more effectively) and AArch64 at all.
> >
> > The current method used in ARM is to expand into a series of
> > store-flag instructions and then hope that combine can optimize them
> > away (though that fails far too often, particularly when the first
> > instruction in the sequence is combined into another pattern).  To
> > make it work at all the compiler has to lie about the costs of various
> > store-flag type operations which overall risks producing worse code
> > and means we also have to support many more complex multi-instruction
> > patterns than is desirable.  I really don't want to go down the same
route
> for AArch64.
> >
> > The idea behind all this is to capture potential conditional compare
> > operations early enough in the mid end that we can keep track of them
> > until RTL expand time and then to emit the correct logic on all
> > targets depending on what is the best thing for that target.  The
> > current method of lowering into store-flag sequences doesn't really cut
it.
> 
> It seems to me that then the initial instruction selection process (aka
RTL
> expansion) needs to be improved.  As we are expanding with having the CFG
> around it should be easy enough to detect AND/ORIF cases and do better
> here.  Yeah, I suppose this asks to turn existing jump expansion
optimizations
> up-side-down to optimize with the GIMPLE CFG in mind.
> 
> The current way of LOGICAL_OP_NON_SHORT_CIRCUIT is certainly bogus -
> fold-const.c is way too early to decide this.  Similar to the ongoing work
of
> expanding / building-up switch expressions in a GIMPLE pass, moving expand
> complexity up the pipeline this asks for a GIMPLE phase that moves this
> decision down closer to RTL expansion.
> (We have tree-ssa-ifcombine.c that is a related GIMPLE transform pass)
>

The patch is updated according to your comments. It is a basic support,
which does not touch ifcombine and jump related optimizations yet.

Current method is:
1) In fold-const, if HAVE_conditional_compare, set
LOGICAL_OP_NON_SHORT_CIRCUIT
   to optimize_function_for_speed_p. So we do not depend on BRANCH_COST.
2) Identify CCMP during expanding. A CCMP candidate is a BIT_AND_EXPR
   or BIT_IOR_EXPR, whose operators are compares.
3) Add a new op in optab to expand the CCMP to optimized RTL,
    e.g. and_scc_scc/ior_scc_scc in ARM.

Bootstrap on ARM Chrome book.
No make check regression on Pandaboard.

Thanks!
-Zhenqiang

ChangeLog:
2013-09-18  Zhenqiang Chen  <zhenqiang.chen@linaro.org>

	* config/arm/arm.md (conditional_compare): New.
	* expr.c (is_conditional_compare_candidate_p, expand_ccmp_expr):
New.
	(expand_expr_real_1): Identify conditional compare.
	* fold-const.c (LOGICAL_OP_NON_SHORT_CIRCUIT): Update.
	* optabs.c (expand_ccmp_op): New.
	(get_rtx_code): Handle BIT_AND_EXPR and BIT_IOR_EXPR.
	* optabs.def (ccmp_optab): New.
	* optabs.h (expand_ccmp_op): New.

Attachment: basic-conditional-compare-support2.patch
Description: Binary data