Re: Reload and reg_equiv_constant

["Ulrich Weigand" <Ulrich dot Weigand at de dot ibm dot com>]

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...

Right.

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

Ulrich Weigand

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