"David Edelsohn" <[EMAIL PROTECTED]> writes: > On Sun, Sep 7, 2008 at 1:58 PM, Richard Sandiford > <[EMAIL PROTECTED]> 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
