-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/09/11 14:09, Kai Tietz wrote: > > Well, such a comparison-logic-folder helper - like affine-tree for > add/subtract/scale) - is for sure something good for inner gimple > passes building up new logic-truth expressions, but such a pass > doesn't meet requirements need to fold for BC optimization AFAICS. Perhaps. I think the thing to do would be to see what additional needs we have and evaluate if they make sense in that kind of framework.
> > The difference is that for BC we don't want to fold at all. Also > it isn't necessarily "simplified" statement we want. For example > 'if ((a | b) == 0 & ...) ...'. If the costs of such pattern '(a | > b) == 0' are too high, we want to representation it instead as 'if > (a == 0) if (b == 0) ...'. We don't have to fold. Think of this as an easy to use on-the-side representation of some operation(s). What I would roughly expect to see is the set of operations feeding the comparison shoved into this structure. With the full set of ops exposed into this structure we could look at the cost, canonicalize/simplify if appropriate, then select the best codegen strategy, modifying the on-the-side structure as needed. We then reflect the final result back into the IL. > We have an condition 'if ((A | B) == 0 && C == 0) ...' where the > joining of A == 0 and C == 0 would be profitable by > BC-optimization, but the join of A != 0 and B != 0 isn't. So we do > - as my patch does - first an expand to element comparison-sequence > view. > > So we get for it the transformed form 'if (A == 0 && B == 0 && C == > 0)'. Right, so one of the first steps would be to canonicalize the (A|B) == 0 && C == 0 form into something like you've shown above within this on-the-side structure. > Now we can begin to search for valid patterns in the condition for > joining by searching from left-to-right for a profitable pattern. > So we end-up with final statement 'if ((A | C) == 0 && C)' Which would be fairly straighforward using the on-the-side structure. I'm not sure what I'm missing since the description you've given fits very nicely with the overall approach Richi is suggesting. jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOvBC4AAoJEBRtltQi2kC7tlcH/RHMWieuVEeJY8HZHw4wroA+ 3Dnz1SFd7wA5kmj+1G+UdT4tl+L6zMdiF0GxwJ2zRh9QBQBCkwk3gBHfsgKSGb1h u3jsUfa/TAVtym6cccIQZ6+ieEGVaARkqzt+dlqKyd+YItkm9nCciYVIaTTBwgsd D6I2GMRrFfPkh1txQQ1sQQ9knnXmTp3YEwiDN3jCbm2dpn6X+jI9fOFJqGNPXrum 3t+d30zHiWlai+T0zfBSNJKOJO/NOU6hU1ShbPDGy3d+YQItXVb6BcSIivu9Jexz c9RNyflJRXY3tKkcMWqbarddbGeyXdnS66tgkIoxXpMp5len46Ion+Y+DJCXV34= =A65E -----END PGP SIGNATURE-----
