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: no_new_pseudos


> I am going to argue that it was a bug that we did not allow new pseudos
> after flow had ran.  And that we should have always allowed pseudos
> before the register allocator.  Since flow was so broken, we could not,
> we added the hack no_new_pseudos get around that problem.  Now we are
> saying it is a nice abstraction but I am saying this abstraction should
> never have happened in the first place.  We now have a better compiler
> due to the removal of the hack.

I don't think that debating whether it's a "bug" or a "feature" is that
relevant.

The way I look at it is that at the start of compilation, you can clearly
create pseudos.  At the end of the process (say, while writing assembler),
you can't.  So there must be some place in the middle where the state of
that attribute changes.  That point will vary as the compiler changes,
hopefully monotonically to the later phases, but perhaps not.

My point is that the back end does not need to know the state of the
technology and hence that exact position in the compilation .


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