On Tue, Dec 10, 2013 at 12:39 PM, Richard Henderson <r...@redhat.com> wrote:
> On 12/10/2013 10:44 AM, Richard Sandiford wrote:
>> Sorry, I don't understand. I never said it was invalid. I said
>> (subreg:SF (reg:V4SF X) 1) was invalid if (reg:V4SF X) represents
>> a single register. On a little-endian target, the offset cannot be
>> anything other than 0 in that case.
>>
>> So the CANNOT_CHANGE_MODE_CLASS code above seems to be checking for
>> something that is always invalid, regardless of the target. That kind
>> of situation should be rejected by target-independent code instead.
>
> But, we want to disable the subreg before we know whether or not (reg:V4SF X)
> will be allocated to a single hard register. That is something that we can't
> know in target-independent code before register allocation.
I tried Kirill's patch. But LRA isn't prepared to handle it:
spawn -ignore SIGHUP /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-1.c
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libatomic/
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libatomic/.libs
-latomic -fno-diagnostics-show-caret -fdiagnostics-color=never -O1
-std=c11 -pedantic-errors -lm -m32 -o ./c11-atomic-exec-1.exe^M
/export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-1.c:
In function 'test_simple_assign':^M
/export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-1.c:81:1:
internal compiler error: Maximum number of LRA constraint passes is
achieved (30)^M
^M
0x88ed77 lra_constraints(bool)^M
/export/gnu/import/git/gcc/gcc/lra-constraints.c:3871^M
0x87fe8c lra(_IO_FILE*)^M
/export/gnu/import/git/gcc/gcc/lra.c:2331^M
0x840f76 do_reload^M
/export/gnu/import/git/gcc/gcc/ira.c:5455^M
0x840f76 rest_of_handle_reload^M
/export/gnu/import/git/gcc/gcc/ira.c:5584^M
0x840f76 execute^M
/export/gnu/import/git/gcc/gcc/ira.c:5613^M
>> In other words I'm arguing against the idea of passing the offset to
>> CANNOT_CHANGE_MODE_CLASS (which you seemed to be supporting in the
>> quote above). I think Kirill's patch to remove the i386.c check was
>> the right way to go.
>
>
> Unless you can figure a way around the above, I think passing the offset to
> C_C_M_C is probably the way to go. I need to have a look over the patches
> though...
>
>>
>> There's no need for a separate insn though. Once you allow the subregs
>> (as per Kirill's patch), the normal move patterns will handle them.
>
> Absolutely.
>
We may need to adjust the existing patterns if subreg is allowed.
I have a few small testcases I can try.
--
H.J.
