public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: gcc-patches@gcc.gnu.org, richard.sandiford@arm.com
Subject: Re: [PATCH] explow, aarch64: Fix force-Pmode-to-mem for ILP32 [PR97269]
Date: Mon, 4 Jan 2021 12:19:23 -0700	[thread overview]
Message-ID: <d06aab67-8d99-f197-ab04-ea6cd175abd3@redhat.com> (raw)
In-Reply-To: <mpt4kjwj56j.fsf@arm.com>



On 1/4/21 4:46 AM, Richard Sandiford via Gcc-patches wrote:
> This patch fixes a mode/rtx mismatch for ILP32 targets in:
>
> 	  mem = force_const_mem (ptr_mode, imm);
>
> where imm can be Pmode rather than ptr_mode.
>
> The patch uses convert_memory_address to convert the Pmode address
> to ptr_mode before the call.  However, immediate addresses can in
> general contain unspecs, and convert_memory_address wasn't set up
> to handle those.
>
> The patch therefore adds some generic unspec handling to
> convert_memory_address_addr_space_1.  As the comment says, we can add
> a target hook if this behaviour turns out to be wrong for some targets.
> But I think what the patch does is a strict improvement over the status
> quo: without it, we would try to force the unspec into a register,
> but nevertheless wrap the result in a (const ...).  That in turn
> would be invalid rtl and seems bound to generate an ICE later.
>
> I tested the explow.c part using -fstack-protector with local hacks
> to force SYMBOL_FORCE_TO_MEM for UNSPEC_SALT_ADDR.
>
> Fixes c-c++-common/torture/pr57945.c and various other tests.
>
> Tested on aarch64-linux-gnu, aarch64_be-elf and x86_64-linux-gnu.
> OK for the explow bits?
>
> Richard
>
>
> gcc/
> 	PR target/97269
> 	* explow.c (convert_memory_address_addr_space_1): Handle UNSPECs
> 	nested in CONSTs.
> 	* config/aarch64/aarch64.c (aarch64_expand_mov_immediate): Use
> 	convert_memory_address to convert symbolic immediates to ptr_mode
> 	before forcing them to memory.
OK.    I can't think of a case where the operand-by-operand conversion
wouldn't work, but as we both know, targets sometimes to "odd" things.  
So a conditional ACK and we'll see how the various targets in the tester
respond.

jeff


      reply	other threads:[~2021-01-04 19:19 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-04 11:46 Richard Sandiford
2021-01-04 19:19 ` Jeff Law [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d06aab67-8d99-f197-ab04-ea6cd175abd3@redhat.com \
    --to=law@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.sandiford@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).