This is the mail archive of the gcc@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]

Re: List of simplifications we should perform


kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

> A quick look shows that we do nearly all (or all) of these.
> 
This doesn't surprise me, actually, CSE keeps removing everything i
throw at it, when i try to test my SSA conditional constant
propagation pass (the main reason for making it SSA based, is that
it'll be easier to use with Diego's tree optimizer framework.  
). I actually have to disable it, and then disable the SSA global
value numbering pass I did, to be able to get enough constants to get
through to thoroughly test propagation.

> I'll try to take a closer look at this list this week and see if any
> are missing (and add them!)

I just posted the gensimplify stuff to gcc-patches. You might want to
look at it before adding more stuff to simplify-rtx.
It just 'feels' a lot easier writing these simplifications in an md
style, using match_operand, etc, than doing it in simplify rtx.

Also, come to think of it, this would solve the problem of fold_rtx
and simplify_rtx divergences.

You could generate the same code, and do the same lookups,  that
fold_rtx does just by adding the right tests to the match_* lists, no?

I just did something similar for the SSA CCP pass, so that it could
lookup lattice values to determine if it was constant.

Before I had added callbacks to every single routine in simplify_rtx,
renamed them, and provided default callbacks that said nothing
!CONSTANT_P was constant, and made the old interface call the new one,
with the default callbacks, so that I didn't have to write my own
evaluation framework.
This was an amazingly serious pain in the ass, as you would imagine,
because of so many places we need to recheck if the operands are
constant, and get the constant values, in the various routines.

We'd also be able to use the (define_simplify) syntax to generate TREE
simplification code, i would imagine, no?

-- 
"I've never seen electricity, so I don't pay for it.  I write
right on the bill, "I'm sorry, I haven't seen it all month."
"-Steven Wright


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