This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][GCC][AARCH64]Bad code-gen for structure/block/unaligned memory access
- From: James Greenhalgh <james dot greenhalgh at arm dot com>
- To: Tamar Christina <Tamar dot Christina at arm dot com>
- Cc: Richard Sandiford <richard dot sandiford at linaro dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>, nd <nd at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>
- Date: Tue, 14 Nov 2017 17:48:03 +0000
- Subject: Re: [PATCH][GCC][AARCH64]Bad code-gen for structure/block/unaligned memory access
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=pass (sender IP is 217.140.96.140) smtp.mailfrom=arm.com; gcc.gnu.org; dkim=none (message not signed) header.d=none;gcc.gnu.org; dmarc=bestguesspass action=none header.from=arm.com;
- Nodisclaimer: True
- References: <VI1PR0801MB20313B74A43EAC4756E8C8BDFFC80@VI1PR0801MB2031.eurprd08.prod.outlook.com> <87a85ic3i1.fsf@linaro.org> <HE1PR0801MB202735017D77BF86B97A82F2FFCE0@HE1PR0801MB2027.eurprd08.prod.outlook.com> <VI1PR0801MB2031C1DB43DDAD286965D8BFFFD60@VI1PR0801MB2031.eurprd08.prod.outlook.com> <20170830155619.GA30919@arm.com> <HE1PR08MB050739ADF44BE7FE11E826FBFF280@HE1PR08MB0507.eurprd08.prod.outlook.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On Tue, Nov 14, 2017 at 04:05:12PM +0000, Tamar Christina wrote:
> Hi James,
>
> I have split off the aarch64 bit off from the generic parts and processed your feedback.
>
> Attached is the reworked patch.
>
> Ok for Tunk?
Thanks for the respin, I'm a bit confused by this comment.
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index e89c8156976cecf200cd67c1e938c8156c1240c4..bc197cc973a2bbc2c263809c7e8ccfbc86309c26 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -13974,6 +13974,28 @@ aarch64_expand_movmem (rtx *operands)
> base = copy_to_mode_reg (Pmode, XEXP (src, 0));
> src = adjust_automodify_address (src, VOIDmode, base, 0);
>
> + /* Optimize routines for MEM to REG copies.
> + This particular function only handles copying to two
> + destination types: 1) a regular register and 2) the stack.
> + When writing to a regular register we may end up writting too much in cases
> + where the register already contains a live value or when no data padding is
> + happening so we disallow regular registers to use this new code path. */
I'm struggling to understand when you'd end up with a struct held in
a partial register going through this code path. Maybe the restriction
makes sense, can you write a testcase, or show some sample code where
this goes wrong (or simplify the comment).
Thanks,
James