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]

Re: RFC: Add of type-demotion pass


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.

Hello,

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, remove_prop_source_from_use, etc.

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 ;-)

--
Marc Glisse


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]