This is the mail archive of the
mailing list for the GCC project.
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: pinskia at gmail dot com
- Cc: Richard dot Earnshaw at arm dot com, aoliva at redhat dot com, bonzini at gnu dot org, dave dot korn at artimi dot com, dje at watson dot ibm dot com, gcc at gcc dot gnu dot org, iant at google dot com, rsandifo at nildram dot co dot uk, stevenb dot gcc at gmail dot com, zadeck at naturalbridge dot com
- Date: Mon, 09 Jul 2007 13:52:57 EDT
- Subject: Re: no_new_pseudos
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <10707091208.AA07438@vlsi1.ultra.nyu.edu> <469238A9.email@example.com> <firstname.lastname@example.org> <email@example.com>
> 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
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 .