Steven Bosscher wrote:
On 4/20/07, Vladimir N. Makarov <[EMAIL PROTECTED]> wrote:
Did not I write several times that the data structure of DF is too fat
(because rtl info duplication) and that is probably the problem?
Yes, you have complained that you believe the data structure of DF is
too fat. I guess that is a valid complaint. I don't see the "rtl info
duplication" though. You've only complained about the current data
structures, but I have not really seen you propose anything leaner.
I did proposed to attach the info to rtl reg. It is more difficult way
than the current approach because of code sharing before the reload.
But may be it is more rewarding. To be honest I don't know.
Is it
not reasonable that using more fat structures without changing
algorithms makes compiler slower?
No, because the "without changing algorithms" is what you're assuming.
But if you look at e.g. e.g. regmove, you see that many of the insn
chain walks could easily be replaced with simpler/faster reg-def
chains, which are always available in the df framework. Likewise for
the changed registers for CPROP, which runs three times(!). It is
easy to really speed this pass up by using the df framework to e.g.
replace things like oprs_unchanged_p and the whole reg_avail_mess.
Sorry, I wrote in several times that I am not against a
df-infrastructure because I believed in the example you just wrote too.
But according to your logic the compiler should be faster. It did not
happen yet because the df advantages is less significant than its
dissadvantages for now imho.
Your argument says me that if you find another such optimization to
rewrite it and speed it up, the df advantages will overtake its
disadvantages and it can be merged without my objections (although who
cares about my opinion). That is my another proposal.
