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 Sun, Sep 13, 2009 at 08:54:24PM +0100, Richard Sandiford wrote:
>> This is probably a dumb question, sorry, but why do you need to
>> strip the CONSTs? I realise you're at least partly doing it for
>> consistency with simplify_unary_operation, but I notice that that
>> function strips the CONST from the original operand ("op")
>> _before_ calling avoid_constant_pool_reference. Here you instead
>> strip the CONST from the "trueopX" variable _after_ calling
>> avoid_constant_pool_reference. Is that a deliberate difference?
>>
>> From a quick scan, all uses of trueop{0,1} in simplify_binary_operation_1
>> and simplify_const_binary_operation appear to be of the form
>> "rtx_equal_p (trueop0, trueop1)" or "GET_CODE (trueopX) == CONST_FOO".
>> Stripping CONSTs shouldn't affect those, because it's invalid to have
>> (const (const_int ...)), (const (const_vector ...)), etc.
>
> 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?
We should really try to avoid a situation where (const:M (const_int X))
is allowed in _some_ places, but can't _always_ be used as a direct
substitute for an M-mode (const_int X). Today it might just be these
simplification routines that need to handle the CONST form, but later,
we'll probably find other places, and before long, there'll be no telling
which routines need to hand the CONST-wrapped forms and which don't.
Sorry for whining. ;-( It's just that I was hit by a similar problem
with (const (minus ...)) a while back. That usage crept into backends,
and then consequently crept into some target-independent code, but because
it was an undocumented construct, not all ports were prepared to handle it.
It also had some unwanted side-effects on ports that did handle it.
Richard