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]

Re: Machine Description for Freedom CPU


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

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