This is the mail archive of the
mailing list for the GCC project.
Re: folding (vec_)cond_expr in a binary operation
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 11 Sep 2013 12:36:15 +0200 (CEST)
- Subject: Re: folding (vec_)cond_expr in a binary operation
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 02 dot 1307061712010 dot 5572 at stedding dot saclay dot inria dot fr> <CAFiYyc0RZYc0+sqj7KSoq2fvF4i+8UuzqqLZ8aXrMhXHKqCshA at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1309021121350 dot 3625 at laptop-mg dot saclay dot inria dot fr> <CAFiYyc1XODgRL=8hVsPd8Ou+W+EEJnU70KC3NoeKttnLHDgQZQ at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1309031344320 dot 11225 at stedding dot saclay dot inria dot fr>
Any other comments on this patch?
On Tue, 3 Sep 2013, Marc Glisse wrote:
(attaching the latest version. I only added comments since regtesting it)
On Tue, 3 Sep 2013, Richard Biener wrote:
Btw, as for the patch I don't like that you basically feed everything
fold. Yes, I know we do that for conditions because that's quite
and nobody has re-written the condition folding as gimple pattern
I doubt that this transform is important enough to warrant another
I am not sure what you want here. When I notice the pattern (a?b:c) op d,
need to check whether b op d and c op d are likely to simplify before
transforming it to a?(b op d):(c op d). And currently I can't see any way
do that other than feeding (b op d) to fold. Even if/when we get a gimple
folder, we will still need to call it in about the same way.
With a gimple folder you'd avoid building trees.
Ah, so the problem is the cost of building those 2 trees? It will indeed
be better when we can avoid it, but I really don't expect the cost to be
You are testing for
a quite complex pattern here - (a?b:c) & (d?e:f).
But it is really handled in several steps. IIRC:
(a?1:0)&x becomes a?(x&1):0.
Since x is d?1:0, x&1 becomes d?1:0.
a?(d?1:0):0 is not (yet?) simplified further.
Now if we compare to 0: a?(d?1:0):0 != 0 simplifies to a?(d?1:0)!=0:0
then a?(d?-1:0):0 and finally a?d:0.
Each step can also trigger individually.
It seems to be that
+ vec c=(a>3)?o:z;
+ vec d=(b>2)?o:z;
+ vec e=c&d;
would be better suited in the combine phase (you are interested in
combining the comparisons). That is, look for a [&|^] b where
a and b are [VEC_]COND_EXPRs with the same values.
Hmm, I am already looking for a binary op which has at least one operand
which is a [VEC_]COND_EXPR, in the combine (=backward) part of
tree-ssa-forwprop. Isn't that almost what you are suggesting?
Heh, and it's not obvious to me with looking for a minute what this should
be simplified to ...
(a?x:y)&(b?x:y) doesn't really simplify in general.
(so the code and the testcase needs some
comments on what you are trying to catch ...)
a<b vectorizes to (a<b)?1:0. If we compute & and | of conditions, we end
up with & and | of vec_cond_expr, and it seems preferable to clean that
up, so ((a<b)?1:0)&((c<d)?1:0) would become ((a<b)&(c<d))?1:0. I don't
quite produce (a<b)&(c<d) but (a<b)?(c<d):0 instead, I guess the last
step (replacing vec_cond_expr with and_expr) would be easy to do at
expansion time if it isn't already. It could also be done earlier, but
we want to be careful since fold_binary_op_with_conditional_arg had
related infinite loops in the past.
This transformation is basically a gimple version of
fold_binary_op_with_conditional_arg, so it applies more widely than just
this vector example.