* SUBREG_PROMOTED_VAR_P handling in expand_direct_optab_fn
@ 2017-09-20 12:21 Richard Sandiford
2017-10-13 19:04 ` Jeff Law
0 siblings, 1 reply; 2+ messages in thread
From: Richard Sandiford @ 2017-09-20 12:21 UTC (permalink / raw)
To: gcc-patches
This is needed by the later SVE LAST reductions, where an 8-bit
or 16-bit result is zero- rather than sign-extended to 32 bits.
I think it could occur in other situations too.
Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linus-gnu.
OK to install?
Richard
2017-09-20 Richard Sandiford <richard.sandiford@linaro.org>
Alan Hayward <alan.hayward@arm.com>
David Sherwood <david.sherwood@arm.com>
gcc/
* internal-fn.c (expand_direct_optab_fn): Don't assign directly
to a SUBREG_PROMOTED_VAR.
Index: gcc/internal-fn.c
===================================================================
--- gcc/internal-fn.c 2017-08-30 12:18:46.627041352 +0100
+++ gcc/internal-fn.c 2017-09-20 13:19:54.460290742 +0100
@@ -2606,7 +2606,15 @@ expand_direct_optab_fn (internal_fn fn,
tree lhs = gimple_call_lhs (stmt);
tree lhs_type = TREE_TYPE (lhs);
rtx lhs_rtx = expand_expr (lhs, NULL_RTX, VOIDmode, EXPAND_WRITE);
- create_output_operand (&ops[0], lhs_rtx, insn_data[icode].operand[0].mode);
+
+ /* Do not assign directly to a promoted subreg, since there is no
+ guarantee that the instruction will leave the upper bits of the
+ register in the state required by SUBREG_PROMOTED_SIGN. */
+ rtx dest = lhs_rtx;
+ if (GET_CODE (dest) == SUBREG && SUBREG_PROMOTED_VAR_P (dest))
+ dest = NULL_RTX;
+
+ create_output_operand (&ops[0], dest, insn_data[icode].operand[0].mode);
for (unsigned int i = 0; i < nargs; ++i)
{
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: SUBREG_PROMOTED_VAR_P handling in expand_direct_optab_fn
2017-09-20 12:21 SUBREG_PROMOTED_VAR_P handling in expand_direct_optab_fn Richard Sandiford
@ 2017-10-13 19:04 ` Jeff Law
0 siblings, 0 replies; 2+ messages in thread
From: Jeff Law @ 2017-10-13 19:04 UTC (permalink / raw)
To: gcc-patches, richard.sandiford
On 09/20/2017 06:21 AM, Richard Sandiford wrote:
> This is needed by the later SVE LAST reductions, where an 8-bit
> or 16-bit result is zero- rather than sign-extended to 32 bits.
> I think it could occur in other situations too.
>
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linus-gnu.
> OK to install?
>
> Richard
>
>
> 2017-09-20 Richard Sandiford <richard.sandiford@linaro.org>
> Alan Hayward <alan.hayward@arm.com>
> David Sherwood <david.sherwood@arm.com>
>
> gcc/
> * internal-fn.c (expand_direct_optab_fn): Don't assign directly
> to a SUBREG_PROMOTED_VAR.
OK.
jeff
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2017-10-13 18:55 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-20 12:21 SUBREG_PROMOTED_VAR_P handling in expand_direct_optab_fn Richard Sandiford
2017-10-13 19:04 ` Jeff Law
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).