This is the mail archive of the
`gcc-patches@gcc.gnu.org`
mailing list for the GCC project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*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? 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 everythingintofold. Yes, I know we do that for conditions because that's quite importantand nobody has re-written the condition folding as gimple patternmatcher.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,Ineed to check whether b op d and c op d are likely to simplify beforetransforming it to a?(b op d):(c op d). And currently I can't see any waytodo 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 shouldbe 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

**References**:**Re: folding (vec_)cond_expr in a binary operation***From:*Marc Glisse

**Re: folding (vec_)cond_expr in a binary operation***From:*Richard Biener

**Re: folding (vec_)cond_expr in a binary operation***From:*Marc Glisse

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |