This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Handle CONST in a few more places in simplify-rtx.c
Jakub Jelinek <jakub@redhat.com> writes:
> On Mon, Sep 14, 2009 at 08:06:47PM +0100, Richard Sandiford wrote:
>> > I guess the earlier can be explained by saying that both cselib and
>> > DEBUG_INSNs use (const:mode (const_int ...)) and (const:mode (const_double ...))
>> > (see wrap_constant) and my patch is just to make sure the extra const isn't
>> > blocking optimization of it.
>>
>> Ugh. If cselib and DEBUG_INSNs do that, we can persuade them to
>> strip them again (via unwrap_constant or whatever) _before_ passing
>> the constant around?
>
> That's what the patch I've posted helps with, getting rid of the (const:M (const_int))
> 's as soon as possible.
I just don't see why it's not possible to get rid of them before
calling the simplification routines. Why is here as soon as possible?
Besides, how we do we know that any function that receives a wrapped
constant, such as via cselib_expand_value_rtx, is going to call a
simplification routine on it, rather than pass the (const (const_int X))
to some other function?
It'd be far better IMO to make any uses of wrap_constant as internal as
possible to the infrastructure that creates them, which means generic
code like the simplification routines shouldn't ever see them.
E.g. why does cselib_expand_value_rtx_1 need to call wrap_constant
at all, given that the mode of the returned constant is the same
as the original rtx? Surely if the caller needs to know the mode,
it will already have access to it? And if the caller passes the
result of cselib_expand_value_rtx on to some other function F
where the mode of the rtx might be in doubt, the convention is
to pass the mode as well as the rtx to F.
Before the VTA merge, cselib only used wrapped constants when doing
hash lookup, which is fine. The wrapped values didn't even get
entered into the hash table; they were entirely local to the lookup.
So why did the VTA merge need this new call in cselib_expand_value_rtx_1?
I'm sure there's a good reason, but I'm wondering if it couldn't be
solved some other way.
Richard