Re: Reload and reg_equiv_constant

[Richard Sandiford <rsandifo at redhat dot com>]

"Ulrich Weigand" <Ulrich.Weigand@de.ibm.com> writes:
> Actually, they're nearly all worse.  In general, we *want* to use
> constant pool entries directly as memory references.
> 
> The only cases I've seen that were arguably improved are those where
> your patch happened to eliminate *all* constants, which means that
> the literal pool register need not be set up.

Yeah, sorry, those were the only ones I meant.

> However, this nearly never occurs in real-world code; you usually need
> a literal pool anyway.

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.

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

> >The problem is that the test in init_reload is for a general symbol_ref,
> >not a constant pool address.  I couldn't think of a good way of fixing
> >this within the current framework.  For example, if we set the dummy
> >symbol's CONSTANT_POOL_ADDRESS_P bit, the backend might pass the
> >symbol to functions like get_pool_mode(), which would then abort.
> 
> 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.

Richard