This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PR37363: PR36090 and PR36182 all over again
"David Edelsohn" <dje.gcc@gmail.com> writes:
> On Sun, Sep 7, 2008 at 1:58 PM, Richard Sandiford
> <rdsandiford@googlemail.com> wrote:
>>> I agree. So your plan would be to change rs6000 to an unspec, and drop
>>> the problematic hunk in simplify-rtx.c? That would be okay with me, but
>>> it's not a small change for rs6000.
>>
>> Yeah, this is very much my preferred option.
>>
>> FWIW, here's a proof-of-concept patch for GNU/Linux and AIX.
>> It knowingly breaks Darwin, so it can't be applied as-is.
>> But if the idea seems OK to David, I'll volunteer to do the
>> Darwin stuff too (including x86 if necessary).
>>
>> I compared the gcc.c-torture, gcc.dg and g++.dg output for the
>> following options:
>>
>> -O2
>> -O2 -fpic
>> -O2 -fPIC
>> -O2 -mminimal-toc
>>
>> on the following targets:
>>
>> powerpc-linux-gnu
>> powerpc64-linux-gnu
>> powerpc-aix4.3
>>
>> and there were no differences.
>
> I do not object in principle to converting the TOC addressing to
> use UNSPEC. We need to ensure that this produces the same
> assembly code, not just lack of testsuite failures.
Yeah, sorry, that's what I meant by the rather vague "differences".
The assembly output was the same in all cases.
> I still think that this is ignoring the issue of simplify-rtx.c versus
> commutative_operand_precedence. Even if rs6000 does not
> rely on this idiom, simplify-rtx.c is re-grouping operands it
> should not change.
Well, my hope is that if we move towards unspecs for this kind of thing,
we can define a simple grammar for CONSTs. See my reply to H-P's
gcc-patches message for details. There wouldn't be any grouping
inside a CONST then: it would either be an unspec base,
or a base + a CONST_INT.
I'll work on a Darwin patch, but it might be a few days...
Richard