This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Machine Description for Freedom CPU
- To: Lee Randolph Salzman <lsalzman+ at andrew dot cmu dot edu>
- Subject: Re: Machine Description for Freedom CPU
- From: Alexandre Oliva <aoliva at redhat dot com>
- Date: 22 Nov 2000 15:52:25 -0200
- Cc: gcc at gcc dot gnu dot org
- Organization: GCC Team, Red Hat
- References: <Added.Mu6hldW00Udg0Cjk40@andrew.cmu.edu>
On Nov 21, 2000, Lee Randolph Salzman <lsalzman+@andrew.cmu.edu> wrote:
> However, the second optimization is turned on, the transitive use of
> the label_ref is transformed into a direct use, i.e. the (set (pc)
> (label_ref ...)) I was trying to get rid of in the first place.
Use a constraint in the (set (pc) (match_operand ...)) instructions
that only accept registers, but let the predicate accept a label_ref.
Then, you don't even have to expand the load first. reload will do it
for you, and you'll get some benefit from some of the jump
optimizations that run before reload. Unfortunately, you'll lose
jump2 and BB reorder, and you'll get little or no cse on registers
that will hold label_refs. Another alternative is to delay the
expansion of branches to a very late stage, such as machine-dependent
reorg, in which you'd manually allocate registers to hold label_refs
after all jump-related optimizations. You could even use lazy code
motion to get the same register shared by multiple uses.
To give credit where credit is due, I got these ideas from Joern
Rennecke and Richard Henderson, with whom I discussed a while ago how
GCC could generate good code for such a machine.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me