From: Richard Biener <richard.guenther@gmail.com>
To: Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [Patch PR target/67366 2/2] [gimple-fold.c] Support movmisalign optabs in gimple-fold.c
Date: Fri, 09 Oct 2015 09:20:00 -0000 [thread overview]
Message-ID: <CAFiYyc0h4TOS+o2EJ_-+ojmeHQr4LhatJ3WAOSG7Pu2CrPDOBg@mail.gmail.com> (raw)
In-Reply-To: <2ab528a7fba51e409cb1018fdb64bd6d3fc07af2.1444312704.git.ramana.radhakrishnan@arm.com>
On Thu, Oct 8, 2015 at 4:10 PM, Ramana Radhakrishnan
<ramana.radhakrishnan@arm.com> wrote:
> This patch by Richard allows for movmisalign optabs to be supported
> in gimple-fold.c. This caused a bit of pain in the testsuite with strlenopt-8.c
> in conjunction with the ARM support for movmisalign_optabs as the test
> was coded up to do different things depending on whether the target
> supported misaligned access or not. However now with unaligned access
> being allowed for different levels of the architecture in the arm backend,
> the concept of the helper function non_strict_align mapping identically
> to the definition of STRICT_ALIGNMENT disappears.
>
> Adjusted thusly for ARM. The testsuite/lib changes were tested with an
> arm-none-eabi multilib that included architecture variants that did not
> support unaligned access and architecture variants that did.
>
> The testing matrix for this patch was:
>
> 1. x86_64 bootstrap and regression test - no regressions.
> 2. armhf bootstrap and regression test - no regressions.
> 3. arm-none-eabi cross build and regression test for
>
> {-marm/-march=armv7-a/-mfpu=vfpv3-d16/-mfloat-abi=softfp}
> {-mthumb/-march=armv8-a/-mfpu=crypto-neon-fp-armv8/-mfloat-abi=hard}
> {-marm/-mcpu=arm7tdmi/-mfloat-abi=soft}
> {-mthumb/-mcpu=arm7tdmi/-mfloat-abi=soft}
>
> with no regressions.
>
> Ok to apply ?
Ok.
Thanks,
Richard.
> Ramana
>
> 2015-10-08 Richard Biener <rguenth@suse.de>
>
> * gimple-fold.c (optabs-query.h): Include
> (gimple_fold_builtin_memory_op): Allow unaligned stores
> when movmisalign_optabs are available.
>
> 2015-10-08 Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
>
> PR target/67366
> * lib/target-supports.exp (check_effective_target_non_strict_align):
> Adjust for arm*-*-*.
> * gcc.target/arm/pr67366.c: New test.
> ---
> gcc/gimple-fold.c | 11 +++++++++--
> gcc/testsuite/gcc.target/arm/pr67366.c | 14 ++++++++++++++
> gcc/testsuite/lib/target-supports.exp | 9 +++++++++
> 3 files changed, 32 insertions(+), 2 deletions(-)
> create mode 100644 gcc/testsuite/gcc.target/arm/pr67366.c
>
> diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
> index a6caaa4..59d496b 100644
> --- a/gcc/gimple-fold.c
> +++ b/gcc/gimple-fold.c
> @@ -63,6 +63,8 @@ along with GCC; see the file COPYING3. If not see
> #include "tree-eh.h"
> #include "gimple-match.h"
> #include "gomp-constants.h"
> +#include "optabs-query.h"
> +
>
> /* Return true when DECL can be referenced from current unit.
> FROM_DECL (if non-null) specify constructor of variable DECL was taken from.
> @@ -709,7 +711,9 @@ gimple_fold_builtin_memory_op (gimple_stmt_iterator *gsi,
> /* If the destination pointer is not aligned we must be able
> to emit an unaligned store. */
> && (dest_align >= GET_MODE_ALIGNMENT (TYPE_MODE (type))
> - || !SLOW_UNALIGNED_ACCESS (TYPE_MODE (type), dest_align)))
> + || !SLOW_UNALIGNED_ACCESS (TYPE_MODE (type), dest_align)
> + || (optab_handler (movmisalign_optab, TYPE_MODE (type))
> + != CODE_FOR_nothing)))
> {
> tree srctype = type;
> tree desttype = type;
> @@ -721,7 +725,10 @@ gimple_fold_builtin_memory_op (gimple_stmt_iterator *gsi,
> srcmem = tem;
> else if (src_align < GET_MODE_ALIGNMENT (TYPE_MODE (type))
> && SLOW_UNALIGNED_ACCESS (TYPE_MODE (type),
> - src_align))
> + src_align)
> + && (optab_handler (movmisalign_optab,
> + TYPE_MODE (type))
> + == CODE_FOR_nothing))
> srcmem = NULL_TREE;
> if (srcmem)
> {
> diff --git a/gcc/testsuite/gcc.target/arm/pr67366.c b/gcc/testsuite/gcc.target/arm/pr67366.c
> new file mode 100644
> index 0000000..1e8b672
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/pr67366.c
> @@ -0,0 +1,14 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target arm_unaligned } */
> +/* { dg-options "-O2" } */
> +
> +typedef unsigned int u32;
> +u32
> +read32 (const void* ptr)
> +{
> + u32 v;
> + __builtin_memcpy (&v, ptr, sizeof(v));
> + return v;
> +}
> +
> +/* { dg-final { scan-assembler "@ unaligned" } } */
> diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
> index 9057a27..4d5b0a3d 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -6262,6 +6262,15 @@ proc check_vect_support_and_set_flags { } {
> # Return 1 if the target does *not* require strict alignment.
>
> proc check_effective_target_non_strict_align {} {
> +
> + # On ARM, the default is to use STRICT_ALIGNMENT, but there
> + # are interfaces defined for misaligned access and thus
> + # depending on the architecture levels unaligned access is
> + # available.
> + if [istarget "arm*-*-*"] {
> + return [check_effective_target_arm_unaligned]
> + }
> +
> return [check_no_compiler_messages non_strict_align assembly {
> char *y;
> typedef char __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__))) c;
next prev parent reply other threads:[~2015-10-09 9:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-08 14:06 [Patch PR target/67366 0/2] Handle misaligned loads and stores for scalars on STRICT_ALIGNMENT targets Ramana Radhakrishnan
2015-10-08 14:06 ` [Patch PR target/67366 1/2] [ARM] - Add movmisalignhi / si patterns Ramana Radhakrishnan
2015-10-08 14:11 ` [Patch PR target/67366 2/2] [gimple-fold.c] Support movmisalign optabs in gimple-fold.c Ramana Radhakrishnan
2015-10-09 9:20 ` Richard Biener [this message]
2015-10-14 17:35 ` Jeff Law
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=CAFiYyc0h4TOS+o2EJ_-+ojmeHQr4LhatJ3WAOSG7Pu2CrPDOBg@mail.gmail.com \
--to=richard.guenther@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=ramana.radhakrishnan@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).