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: [PATCH][0/n] Merge from match-and-simplify


On 10/20/14 05:42, Richard Biener wrote:
That was a conscious decision and the idea was that the caller should
do this via its lattice valueization function which could look like

tree
valueize (tree t)
{
   if (TREE_CODE (t) == SSA_NAME
       && !has_single_use (t))
     return NULL_TREE;
   return t;
}

But of course doing that unconditionally would also pessimize code.
Generally we'd like to avoid un-CSEing stuff in a way that cannot
be CSEd again.  That's a more complex condition than what can be
implemented with has_single_use.  You might also consider a
stmt doing a_1 + a_1 where a_1 has two uses now.
FWIW, I wouldn't worry much about the two uses in a single statement case. I looked at that in RTL eons ago it just doesn't happen enough to bother trying to detect and treat as a single use.


I thought about doing all simplifications first without committing
any simplified sequence to the IL, then scanning over the result,
pruning out cases that end up pessimizing code (how exactly isn't
yet clear to me).

So I'm not sure what we want to do here now.  I don't very much like
doing things explicitely in the pattern description (nor using the
"has_single_use" predicate).
I suppose for the gimple_build () stuff we could restrict simplifications
to the expression we are building (not simplifying with SSA defs in the
IL), more exactly mimicing fold_buildN behavior.
I suppose for forwprop we could use the above valueize hook (but then
regress because not all patterns as implemented in forwprop guard
their def stmt lookup with has_single_use...).

Any opinion on this?  Any idea of a "simple" cost function if
you have the functions IL before and after simplifications (but
without any DCE/CSE applied)?
It's certainly ideal to be able to be able to CSE/un-CSE depending on final context and it's a design goal I've heard other compiler developers making. ie, every transformation early which may be somewhat speculative must be "un-doable" later. But the infrastructure for that is, umm, hard.

The concept of simplify on the side, then prune out stuff that isn't profitable is nice, but as you state, that's nontrivial as well.

In general, the has_single_use case is profitable. So we want to aggressively go after those and I think we can commit those immediately and use the valueize function shown above.

Maybe you then look at the more speculative cases...

jeff


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