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]
Other format: [Raw text]

Re: local data flow


Kenneth Zadeck wrote:

I would be very careful to tread here. regstack is a can of worms and
not very good worms. We have had a lot of trouble retrofitting better
dataflow into regstack because of the fragile nature of it's
implementation.


Well, the approach so far has been 'don't touch change any register allocation
for stack regs after reg_stack'. I.e. if cross-jumping sees any stack regs, it
considers only literal matches. That should be safe.
The only question that arises here is how we should compute the regsets
when we split a block.


If you think that your cross jumping would be good to do as an
interleaved pass to if conversion, it is possible to see the benefit
there.

There seems to be a misunderstanding here. I have code that is supposed
to be used both by if-conversion and by crossjumping. But I have not proposed
to run both optimizations interleaved, not am I aware of any benefit that would
have.
Most of the higher-level if-conversion transformations can only be done
before register allocation.
Our corss-jumping code is supposed to be run after register allocation,
and I suspect running it before register allocation (which I believe would require
some changes first) would be rather bad for speed optimizations - basically the
antithesis of treegion formation.



However, I think that the code gets hardened a lot by register
allocation in it is difficult for me to see how heroic transformations
are going to be really useful after that pass.


Anyway, many compilers do label the stack and do dataflow on the
individual stack elements. GCC is problematic because most of the stack
off are set in register allocation, and in truth it really is too late
to get much benefit after that pass. But it is not hard to define a
problem that did label the stack elements.


I'm really not very interested in doing optimizations on reg-stack accesses. I just
want to be able to do some more intelligent crossjumping, which happens to take
place after regstack. Only one processor family uses regstack, and even there
it is only relevant in fp-heavy code, and might become obsolescent because of
saner IEEE behaviour and pipelinabiliy of SSE instructions.



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