This is the mail archive of the
mailing list for the GCC project.
Re: RFC: Add of type-demotion pass
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Kai Tietz <ktietz at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 8 Jul 2013 22:52:42 +0200 (CEST)
- Subject: Re: RFC: Add of type-demotion pass
- References: <155227895 dot 847667 dot 1373305519786 dot JavaMail dot root at redhat dot com>
- Reply-to: GCC Patches <gcc-patches at gcc dot gnu dot org>
On Mon, 8 Jul 2013, Kai Tietz wrote:
These passes are implementing type-demotion (type sinking into
statements) for some gimple statements. I limitted inital
implementation to the set of multiply, addition, substraction, and
binary-and/or/xor. Additional this pass adds some rules to sink
type-cast sequences - eg. (int) (short) x; with char as type of x.
This special handing in this pass of such type-sequence simplification
is necessary to avoid too complex cast-sequences by type-unsigned
conversion used by this pass to avoid undefined overflow behaviour.
thanks for working on this. This seems like a nice chance for me to learn,
so I am trying to understand your patch, and I would be glad if you could
give me a couple hints.
I wonder why you implemented this as a separate pass instead of adding it
to tree-ssa-forwprop. demote_cast is (or should be) a special case of
combine_conversions, so it would be nice to avoid the code duplication
(there is also a version in fold-const.c). demote_into could be called
from roughly the same place as simplify_conversion_from_bitmask. And you
could reuse get_prop_source_stmt, can_propagate_from,
If I understand, the main reason is because you want to go through the
statements in reverse order, since this is the way the casts are being
propagated (would forwprop also work, just more slowly, or would it miss
opportunities across basic blocks?).
I have some trouble understanding why something as complicated as
build_and_add_sum (which isn't restricted to additions by the way) is
needed. Could you add a comment to the code explaining why you need to
insert the statements precisely there and not for instance just before
their use? Is that to try and help CSE?
I have added an additional early pass "typedemote1" to this patch for simple cases types can be easily sunken into statement without special unsigned-cast for overflow-case. Jakub asked for it. Tests have shown that this pass does optimizations in pretty few cases. As example in testsuite see for example pr46867.c testcase.
The second pass (I put it behind first vrp pass to avoid testcase-conflicts) uses 'unsigned'-type casts to avoid undefined overflow behavior. This pass has much more hits in standard code,
I assume that, when the pass is done, we can consider removing the
corresponding code from the front-ends? That would increase the hits ;-)