This is the mail archive of the
mailing list for the GCC project.
Re: Reload and reg_equiv_constant
- From: "Ulrich Weigand" <Ulrich dot Weigand at de dot ibm dot com>
- To: Richard Sandiford <rsandifo at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 25 Aug 2003 20:22:47 +0200
- Subject: Re: Reload and reg_equiv_constant
Richard Sandiford wrote:
>Figures ;) But my point was really that, even though the results are
>much worse overall, one or two functions do benefit. Perhaps we could
>get the best of both worlds somehow, maybe by taking current_function_
>uses_const_pool into account or something.
What I'm currently thinking of is to use a call-clobbered register
as literal pool pointer in small leaf functions (which is the only
case where we possibly could get away without literal pool).
Then the overhead of using a literal pool is just one single instruction
(because you don't need to save/restore the pool pointer register), and
this is amortized already with the first use that saves one reload insn.
>There again, it might be such a corner case that it isn't worth bothering.
>And I guess it doesn't have a great deal to do with my patch...
>> What about doing a dummy force_const_mem of, say, const0_rtx? The
>> constant pool mechanism shouldn't actually emit the constant if it
>> isn't really used ...
>Well, this is done in init_reload. I didn't think it was correct
>to call force_const_mem outside of a function context.
Hmmm. The only other thing I can think of is to not use a global flag
but actually check each real case in find_reloads itself ...
However, we certainly need to make sure the right decision is made
on s390; if that requires a new target macro, so be it (IMO).
Mit freundlichen Gruessen / Best Regards
Dr. Ulrich Weigand
Linux for S/390 Design & Development
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
Phone: +49-7031/16-3727 --- Email: Ulrich.Weigand@de.ibm.com