This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] cse.c: Split fold_rtx.
- From: Jeffrey A Law <law at redhat dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: Kazu Hirata <kazu at cs dot umass dot edu>, gcc-patches at gcc dot gnu dot org
- Date: Sat, 05 Mar 2005 22:49:23 -0700
- Subject: Re: [patch] cse.c: Split fold_rtx.
- Organization: Red Hat, Inc
- References: <Pine.LNX.4.44.0503052158090.3797-100000@www.eyesopen.com>
- Reply-to: law at redhat dot com
On Sat, 2005-03-05 at 22:12 -0700, Roger Sayle wrote:
> Does anyone have a good feeling for the issues with RTL's CSE, GCSE
> and cselib in the post-tree-ssa GCC? Clearly, all of the generic
> transformations/simplification need to be moved from fold_rtx into
> simplify_rtx, but beyond that, other than eliminate jump following
> in CSE, and jump bypassing in GCSE, the crystal balls gets misty.
It's even worse than you think. There's another set of simplification
routines in combine.c :(
simplify_rtx simplifies assuming no knowledge about the values
in question.
fold_rtx knows about certain equivalences. ie, it might know that
a particular pseudo has a particular value, which in turn may allow
it to simplify an RTL expression.
The combine simplification routines know about things like how
many high order bits are just copies of the sign bit, or what
bits are known to be zero in a register.
This is not terribly unlike the situation we find ourselves in
with fold at the tree level -- which we haven't yet managed to
solve.
Conceptually, can we devise a folder for either trees or RTL
which can support the different folding needs of the different
passes? IMHO, if we are ever going to find a way to do that, I
think we have to start with a design which lets the folder
query for properties of a register (or SSA_NAME in the case
of the tree folder). Beyond that, I haven't really gotten anywhere.
jeff