On Nov 10, 2015, Alan Lawrence <alan.lawre...@arm.com> wrote:
> FAIL: gcc.target/aarch64/aapcs64/func-ret-4.c execution, -O2
Ugh, sorry. I even checked that testcase by hand before submitting the
patch, because I knew it took the paths I was changing, but I didn't
realize the stack store and load would amount to shifts when the stack
slot was bypassed.
With the following patch, we get a lsr and a ubfx, without the sp
adjustments. Please let me know if it causes any further problems. So
far, I've tested it on x86_64-linux-gnu, i686-linux-gnu, and
ppc64le-linux-gnu; the ppc64-linux-gnu test run is running slower and
probably won't be done before I call it a day, but I wanted to give you
something before taking off for the day.
Is this ok to install if ppc64-linux-gnu also regstraps successfully?
[PR67753] adjust for padding when bypassing memory in assign_parm_setup_block
From: Alexandre Oliva <aol...@redhat.com>
Storing a register in memory as a full word and then accessing the
same memory address under a smaller-than-word mode amounts to
right-shifting of the register word on big endian machines. So, if
BLOCK_REG_PADDING chooses upward padding for BYTES_BIG_ENDIAN, and
we're copying from the entry_parm REG directly to a pseudo, bypassing
any stack slot, perform the shifting explicitly.
This fixes the miscompile of function_return_val_10 in
gcc.target/aarch64/aapcs64/func-ret-4.c for target aarch64_be-elf
introduced in the first patch for 67753.
for gcc/ChangeLog
PR rtl-optimization/67753
PR rtl-optimization/64164
* function.c (assign_parm_setup_block): Right-shift
upward-padded big-endian args when bypassing the stack slot.
---
gcc/function.c | 44 +++++++++++++++++++++++++++++++++++++++++---
1 file changed, 41 insertions(+), 3 deletions(-)
diff --git a/gcc/function.c b/gcc/function.c
index a637cb3..1ee092c 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -3002,6 +3002,38 @@ assign_parm_setup_block (struct assign_parm_data_all
*all,
emit_move_insn (change_address (mem, mode, 0), reg);
}
+#ifdef BLOCK_REG_PADDING
+ /* Storing the register in memory as a full word, as
+ move_block_from_reg below would do, and then using the
+ MEM in a smaller mode, has the effect of shifting right
+ if BYTES_BIG_ENDIAN. If we're bypassing memory, the
+ shifting must be explicit. */
+ else if (!MEM_P (mem))
+ {
+ rtx x;
+
+ /* If the assert below fails, we should have taken the
+ mode != BLKmode path above, unless we have downward
+ padding of smaller-than-word arguments on a machine
+ with little-endian bytes, which would likely require
+ additional changes to work correctly. */
+ gcc_checking_assert (BYTES_BIG_ENDIAN
+ && (BLOCK_REG_PADDING (mode,
+ data->passed_type, 1)
+ == upward));
+
+ int by = (UNITS_PER_WORD - size) * BITS_PER_UNIT;
+
+ x = gen_rtx_REG (word_mode, REGNO (entry_parm));
+ x = expand_shift (RSHIFT_EXPR, word_mode, x, by,
+ NULL_RTX, 1);
+ x = force_reg (word_mode, x);
+ x = gen_lowpart_SUBREG (GET_MODE (mem), x);
+
+ emit_move_insn (mem, x);
+ }
+#endif
+
/* Blocks smaller than a word on a BYTES_BIG_ENDIAN
machine must be aligned to the left before storing
to memory. Note that the previous test doesn't
@@ -3023,14 +3055,20 @@ assign_parm_setup_block (struct assign_parm_data_all
*all,
tem = change_address (mem, word_mode, 0);
emit_move_insn (tem, x);
}
- else if (!MEM_P (mem))
- emit_move_insn (mem, entry_parm);
else
move_block_from_reg (REGNO (entry_parm), mem,
size_stored / UNITS_PER_WORD);
}
else if (!MEM_P (mem))
- emit_move_insn (mem, entry_parm);
+ {
+ gcc_checking_assert (size > UNITS_PER_WORD);
+#ifdef BLOCK_REG_PADDING
+ gcc_checking_assert (BLOCK_REG_PADDING (GET_MODE (mem),
+ data->passed_type, 0)
+ == upward);
+#endif
+ emit_move_insn (mem, entry_parm);
+ }
else
move_block_from_reg (REGNO (entry_parm), mem,
size_stored / UNITS_PER_WORD);
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
