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

[Richard Biener <richard dot guenther at gmail dot com>]

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)

Richard.

> R.
>