[Bug target/83009] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[avieira at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83009

--- Comment #11 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Thu Jul 19 14:03:21 2018
New Revision: 262881

URL: https://gcc.gnu.org/viewcvs?rev=262881=gcc=rev
Log:
[AArch64][PATCH 2/2] PR target/83009: Relax strict address checking for store
pair lanes

gcc/ChangeLog
2018-07-19  Andre Vieira  

PR target/83009
* config/aarch64/predicates.md (aarch64_mem_pair_lanes_operand): Make
address check not strict.

gcc/testsuite/ChangeLog
2018-07-19  Andre Vieira  

PR target/83009
* gcc/target/aarch64/store_v2vec_lanes.c: Add extra tests.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/predicates.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c

[Bug target/83009] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[avieira at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83009

--- Comment #10 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Wed May 30 15:59:14 2018
New Revision: 260957

URL: https://gcc.gnu.org/viewcvs?rev=260957=gcc=rev
Log:
Reverting r260635

gcc
2018-05-30  Andre Vieira  

2018-05-24  Andre Vieira  

PR target/83009
Revert:
* config/aarch64/predicates.md (aarch64_mem_pair_lanes_operand): Make
address check not strict.

gcc/testsuite
2018-05-30  Andre Vieira  

2018-05-24  Andre Vieira  
Revert
PR target/83009
* gcc/target/aarch64/store_v2vec_lanes.c: Add extra tests.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@260635
138bc75d-0d04-0410-961f-82ee72b054a4

Modified:
trunk/gcc/config/aarch64/predicates.md
trunk/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c

[Bug target/83009] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[avieira at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83009

avieira at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from avieira at gcc dot gnu.org ---
I believe my patch fixes this.

[Bug target/83009] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[avieira at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83009

--- Comment #8 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Thu May 24 08:53:39 2018
New Revision: 260635

URL: https://gcc.gnu.org/viewcvs?rev=260635=gcc=rev
Log:
PR target/83009: Relax strict address checking for store pair lanes

The operand constraint for the memory address of store/load pair lanes was
enforcing strictly hardware registers be allowed as memory addresses.  We want
to relax that such that these patterns can be used by combine.  During register
allocation the register constraint will enforce the correct register is chosen.

gcc
2018-05-24  Andre Vieira  

PR target/83009
* config/aarch64/predicates.md (aarch64_mem_pair_lanes_operand): Make
address check not strict.

gcc/testsuite
2018-05-24  Andre Vieira  

PR target/83009
* gcc/target/aarch64/store_v2vec_lanes.c: Add extra tests.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/predicates.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c

[Bug target/83009] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[avieira at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83009

--- Comment #7 from avieira at gcc dot gnu.org ---
Bootstrap and regression testing looks good. Ill put the patch up on the ML
when we enter stage 1 again.

[Bug target/83009] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83009

--- Comment #6 from ktkachov at gcc dot gnu.org ---
(In reply to avieira from comment #5)
> I have been looking at this and the problem does indeed lie with the
> register not being a hard reg because aarch64_mem_pair_lanes_operand invokes
> aarch64_legitimate_address_p with 1 for the strict_p argument.
> 
> Changing that to a 0 yields the desired results for this testcase. Also good
> to note that this is not an ilp32 issue only, because of this we would also
> miss cases where the argument hard-register would not be successfully
> combined into the load/store. Say if for instance the argument in the test
> function were a pointer to the pointer we are addressing.
> 
> I will proceed to run tests now, if someone knows why that "strict_p" was
> being set to 1  please let me know, I am unfamiliar with this code and fear
> this might be too big a hammer.

I think requiring strict address checking in aarch64_mem_pair_lanes_operand is
overly conservative indeed. The store_pair_lanes pattern that uses it is
supposed to be created at combine-time at which point we want to allow any type
of register. Then during reg-alloc the Uml constraint enforces the strict
checking.

So I think relaxing aarch64_mem_pair_lanes_operand is the right way forward,
though of course testing will show.

[Bug target/83009] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[avieira at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83009

--- Comment #5 from avieira at gcc dot gnu.org ---
I have been looking at this and the problem does indeed lie with the register
not being a hard reg because aarch64_mem_pair_lanes_operand invokes
aarch64_legitimate_address_p with 1 for the strict_p argument.

Changing that to a 0 yields the desired results for this testcase. Also good to
note that this is not an ilp32 issue only, because of this we would also miss
cases where the argument hard-register would not be successfully combined into
the load/store. Say if for instance the argument in the test function were a
pointer to the pointer we are addressing.

I will proceed to run tests now, if someone knows why that "strict_p" was being
set to 1  please let me know, I am unfamiliar with this code and fear this
might be too big a hammer.

[Bug target/83009] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[avieira at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83009

avieira at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||avieira at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |avieira at gcc dot 
gnu.org

[Bug target/83009] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83009

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|ktkachov at gcc dot gnu.org|unassigned at gcc dot 
gnu.org

[Bug target/83009] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83009

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P1  |P3
   Target Milestone|8.0 |9.0
Summary|[8 regression]  |gcc.target/aarch64/store_v2
   |gcc.target/aarch64/store_v2 |vec_lanes.c fails with
   |vec_lanes.c fails with  |-mabi=ilp32
   |-mabi=ilp32 |

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Test is XFAILed.
Codegen improvement for ILP32 is not a blocker for GCC 8