[testsuite] Enable pr94600-{1,3}.c tests for nvptx
authorTom de Vries <tdevries@suse.de>
Thu, 1 Oct 2020 09:08:58 +0000 (11:08 +0200)
committerTom de Vries <tdevries@suse.de>
Thu, 1 Oct 2020 10:53:36 +0000 (12:53 +0200)
commit8d268d75ad74772a7e97b86c72da0b5906d8c4d7
treef383eb3e1828a358a44eae3e5c455215d2f55674
parent56da736cc6ced0f1c339744321a14ae569db8606
[testsuite] Enable pr94600-{1,3}.c tests for nvptx

When compiling test-case pr94600-1.c for nvptx, this gimple mem move:
...
  MEM[(volatile struct t0 *)655404B] ={v} a0[0];
...
is expanded into a memcpy, but when compiling pr94600-2.c instead, this similar
gimple mem move:
...
  MEM[(volatile struct t0 *)655404B] ={v} a00;
...
is expanded into a 32-bit load/store pair.

In both cases, emit_block_move is called.

In the latter case, can_move_by_pieces (4 /* byte-size */, 32 /* bit-align */)
is called, which returns true (because by_pieces_ninsns returns 1, which is
smaller than the MOVE_RATIO of 4).

In the former case, can_move_by_pieces (4 /* byte-size */, 8 /* bit-align */)
is called, which returns false (because by_pieces_ninsns returns 4, which is
not smaller than the MOVE_RATIO of 4).

So the difference in code generation is explained by the alignment.  The
difference in alignment comes from the move sources: a0[0] vs. a00.  Both
have the same type with 8-bit alignment, but a00 is on stack, which based on
the base stack align and stack variable placement happens to result in a
32-bit alignment.

Enable test-cases pr94600-{1,3}.c for nvptx by forcing the currently 8-byte
aligned variables to have a 32-bit alignment for STRICT_ALIGNMENT targets.

Tested on nvptx.

gcc/testsuite/ChangeLog:

2020-10-01  Tom de Vries  <tdevries@suse.de>

* gcc.dg/pr94600-1.c: Force 32-bit alignment for a0 for !non_strict_align
targets.  Remove target clauses from scan tests.
* gcc.dg/pr94600-3.c: Same.
gcc/testsuite/gcc.dg/pr94600-1.c
gcc/testsuite/gcc.dg/pr94600-3.c