This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Add of type-demotion pass
- From: Kai Tietz <ktietz at redhat dot com>
- To: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 9 Jul 2013 05:03:26 -0400 (EDT)
- Subject: Re: RFC: Add of type-demotion pass
- References: <155227895 dot 847667 dot 1373305519786 dot JavaMail dot root at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1307082119400 dot 3917 at laptop-mg dot saclay dot inria dot fr>
----- Original Message -----
> 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 try.
> 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.
Initial patch (from last year) actual implemented that in forwprop. I was then kindly asked to put this into a separate pass. There are some good reason why forward-propagation isn't the right place for it. Eg, forwprop does type-raising by default. So by implementing type-demotion there too, would lead to raise-condition. So there would be required additionally that within forwprop a straight line-depth conversion is done for statement-lists. All this doesn't fit pretty well into current concept of forward-propagation ...
The cast demotion is of course something of interest for folding and might be fitting into forward-propagation-pass too. The main cause why it is implemented within demotion pass is, that this pass introduces such cast-demotion-folding opportunities due its "unsigned"-type expansion. So we want
to fold that within pass and not waiting until a later pass optimizes such redundant sequences away.
Btw, the cast-demotion can be still improved for some cases - see here as example the gcc.target/i386/rotate-1.c testcase for such an improvement - so that some expressions of the form of (type1) (((type2) x) op ((type2) y)) can be transformed into x op y.
> 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?).
It would miss some opportunities, and causes penalty on speed due concept of forwprop.
> 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?
Yes, this function is a bit more complex as actual required for now in general. Nevertheless required. And I expect that demotion-pass will improve and so even the right now "unlikely" cases might be required more frequent. I had in front lighter version of statement addition, but it failed in some cases.In some (rare) cases we would otherwise choose wrong basic-block to add the new "cast"-statements. Well, there is another place (reassoc) where you can find nearly the same function, and its needs are exactly the same as within demote-pass.
> > 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 ;-)
Hmm, well possible, but unlikely. FE and ME are two pretty different things. Sadly stuff isn't as clearly separated as it should be. But well, I know there is work going on to achieve that in this area.
> --
> Marc Glisse
>
Kai