public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <jeffreyalaw@gmail.com>
To: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH v2] [PR100106] Reject unaligned subregs when strict alignment is required
Date: Sat, 9 Jul 2022 11:14:56 -0600	[thread overview]
Message-ID: <851ff0bb-4f4a-26da-36da-8276f728415e@gmail.com> (raw)
In-Reply-To: <orfslnfkm1.fsf_-_@lxoliva.fsfla.org>



On 5/5/2022 8:41 PM, Alexandre Oliva via Gcc-patches wrote:
> On May  5, 2022, Segher Boessenkool <segher@kernel.crashing.org> wrote:
>
>> On Thu, May 05, 2022 at 03:52:01AM -0300, Alexandre Oliva wrote:
>>> +  else if (reg && MEM_P (reg)
>>> +	   && STRICT_ALIGNMENT && MEM_ALIGN (reg) < GET_MODE_ALIGNMENT (omode))
>>> +    return false;
>> Please fix the line breaks?  Either do a break before every &&, or put
>> as many things as possible on one line?
> I was going for conceptual grouping of alignment-related subexprs,
> but I don't care enough to fight for it.
>
>> Note that you should never have paradoxical subregs of mem on rs6000 or
>> any other target with INSN_SCHEDULING.
> Great, that alleviates some of my concerns about overreaching in this patch.
>
>>> +#include "../../gcc.c-torture/compile/pr100106.c"
>> It is better to copy the 11 lines of code.
> 'k
>
>> Please comment what the ilp32 is for (namely, the -mcpu= will barf
>> without it)..
> Ack
>
>> The testcase is okay with those changes, thanks!
> Thanks.  Here's the revised patch.
>
> I'm now testing on several platforms a follow-up patch that introduces
> TARGET_ALLOW_SUBREG_OF_MEM.
>
>
> [PR100106] Reject unaligned subregs when strict alignment is required
>
> From: Alexandre Oliva <oliva@adacore.com>
>
> The testcase for pr100106, compiled with optimization for 32-bit
> powerpc -mcpu=604 with -mstrict-align expands the initialization of a
> union from a float _Complex value into a load from an SCmode
> constant pool entry, aligned to 4 bytes, into a DImode pseudo,
> requiring 8-byte alignment.
>
> The patch that introduced the testcase modified simplify_subreg to
> avoid changing the MEM to outermode, but simplify_gen_subreg still
> creates a SUBREG or a MEM that would require stricter alignment than
> MEM's, and lra_constraints appears to get confused by that, repeatedly
> creating unsatisfiable reloads for the SUBREG until it exceeds the
> insn count.
>
> Avoiding the unaligned SUBREG, expand splits the DImode dest into
> SUBREGs and loads each SImode word of the constant pool with the
> proper alignment.
>
>
> for  gcc/ChangeLog
>
> 	PR target/100106
> 	* emit-rtl.cc (validate_subreg): Reject a SUBREG of a MEM that
> 	requires stricter alignment than MEM's.
>
> for  gcc/testsuite/ChangeLog
>
> 	PR target/100106
> 	* gcc.target/powerpc/pr100106-sa.c: New.
OK.
jeff


  reply	other threads:[~2022-07-09 17:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-05  6:52 [PATCH] " Alexandre Oliva
2022-05-05  7:59 ` Richard Sandiford
2022-05-05 13:50   ` Segher Boessenkool
2022-05-06 10:57     ` [PATCH v2 2/2] " Alexandre Oliva
2022-05-09  8:09       ` Richard Sandiford
2022-05-05 14:33 ` [PATCH] " Segher Boessenkool
2022-05-06  2:41   ` [PATCH v2] " Alexandre Oliva
2022-07-09 17:14     ` Jeff Law [this message]
2023-05-24  5:39     ` Alexandre Oliva
2023-05-24  9:04       ` Richard Biener
2024-06-12 12:39     ` Maciej W. Rozycki
2024-06-13  7:36       ` [PATCH] [alpha] adjust MEM alignment for block move [PR115459] (was: Re: [PATCH v2] [PR100106] Reject unaligned subregs when strict alignment is required) Alexandre Oliva
2024-06-13 11:49         ` Maciej W. Rozycki
2024-06-13 15:21           ` Joseph Myers
2024-06-18  9:59           ` Maciej W. Rozycki
2022-05-06 18:04 ` [PATCH] [PR100106] Reject unaligned subregs when strict alignment is required Vladimir Makarov

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=851ff0bb-4f4a-26da-36da-8276f728415e@gmail.com \
    --to=jeffreyalaw@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    /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).