On Fri, 6 Dec 2019, Richard Biener wrote:
Although that will increase the code size. In case, we could still have both a
nop_convert and a strip_nop predicates. Just thinking:
We should measure it, yes, I hope it won't be too bad ;) In theory
making genmatch emitted code more like a graph rather than a tree
(with shared leafs) might save us a bit here.
Indeed, it isn't worth hacking this specific case. If we really want those
savings, making it automatic at a higher level is the right way to go.
On Fri, 6 Dec 2019, Richard Biener wrote:
@@ -1684,7 +1681,7 @@ (define_operator_list COND_TERNARY
/* For equality, this is also true with wrapping overflow. */
(for op (eq ne)
(simplify
- (op:c (nop_convert@3 (plus:c@2 @0 (convert1? @1))) (convert2? @1))
+ (op:c (nop_convert?@3 (plus:c@2 @0 (convert1? @1))) (convert2? @1))
(if (ANY_INTEGRAL_TYPE_P (TREE_TYPE (@0))
&& (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0))
|| TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0)))
Possible future clean-up: those convert1 and convert2 have (strange)
associated tree_nop_conversion_p below and look like candidates to become
nop_convert.
@@ -2159,25 +2156,25 @@ (define_operator_list COND_TERNARY
/* A - (A +- B) -> -+ B */
/* A +- (B -+ A) -> +- B */
(simplify
- (minus (nop_convert (plus:c (nop_convert @0) @1)) @0)
+ (minus (nop_convert1? (plus:c (nop_convert2? @0) @1)) @0)
(view_convert @1))
I was wondering if we could use nop_convert for both (instead of
nop_convert1 and 2), but for constants that wouldn't work, so this looks
good.
--
Marc Glisse
