Any other comments on this patch?
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00129.html
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
into
fold. Yes, I know we do that for conditions because that's quite
important
and nobody has re-written the condition folding as gimple pattern
matcher.
I doubt that this transform is important enough to warrant another
exception ;)
I am not sure what you want here. When I notice the pattern (a?b:c) op d,
I
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
to
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
that much...
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
for example
+ 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.
--
Marc Glisse
