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] cse.c: Split fold_rtx.


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



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