Re: [PATCH 1/1] sparc: support for -mmisalign in the SPARC M8
Just a followup on this patch. We did some run-time performance testing internally on this set of change on sparc M8 machine with -mmisalign and -mno-misalign based on the latest upstream gcc for CPU2017 C/C++ SPEED run: ***without -O, -mmisalign slowdown the run-time performance about 4% on average This is mainly due to the following workaround to misaligned support in M8: (config/sparc/sparc.c) +/* for misaligned ld/st provided by M8, the IMM field is 10-bit wide + other than the 13-bit for regular ld/st. + The best solution for this problem is to distinguish each ld/st + whether it's aligned or misaligned. However, due to the current + design of the common routine TARGET_LEGITIMATE_ADDRESS_P, only + the ADDR of a ld/st is passed to the routine, the align info + carried by the corresponding MEM is NOT passed in. without changing + the prototype of TARGET_LEGITIMATE_ADDRESS_P, we cannot use this + best solution. + as a workaround, we have to conservatively treat ALL IMM field of + a ld/st insn on a MISALIGNED target is 10-bit wide. + the side-effect of this workaround is: there will be additiona + REG<-IMM insn generated for regular ld/st when -mmisalign is ON. + However, such additional reload insns should be very easily to be + removed by a set of optimization whenever -O specified. +*/ +#define RTX_OK_FOR_OFFSET_P(X, MODE) \ + (CONST_INT_P (X) \ + && ((!TARGET_MISALIGN \ +&& INTVAL (X) >=3D3D -0x1000 \ +&& INTVAL (X) <=3D3D (0x1000 - GET_MODE_SIZE (MODE)))\ +|| (TARGET_MISALIGN \ +&& INTVAL (X) >=3D3D -0x0400 \ +&& INTVAL (X) <=3D3D (0x0400 - GET_MODE_SIZE (MODE) due to this run-time regression introduced by this workaround is not trivial, We decided to hold on this set of change at this time. Thanks. Qing > > This set of change is to provide a way to use misaligned load/store insns to > implement the compiler-time known unaligned memory access, -mno-misalign can > be used > to disable such behavior very easily if our performance data shows that > misaligned load/store insns are slower than the current software emulation. > > Qing
Re: [PATCH 1/1] sparc: support for -mmisalign in the SPARC M8
> On Aug 3, 2017, at 11:40 AM, David Miller wrote: > > From: Qing Zhao > Date: Thu, 3 Aug 2017 10:37:15 -0500 > >> all the special handling on STRICT_ALIGNMENT or >> SLOW_UNALIGNMENT_ACCESS in these codes have the following common >> logic: >> >> if the memory access is known to be not-aligned well during >> compilation time, if the targeted platform does NOT support faster >> unaligned memory access, the compiler will try to make the memory >> access aligned well. Otherwise, if the targeted platform supports >> faster unaligned memory access, it will leave the compiler-time >> known not-aligned memory access as it, later the hardware support >> will kicked in for these unaligned memory access. >> >> this behavior is consistent with the high level definition of >> STRICT_ALIGNMENT. > > That's exactly the problem. > > What you want with this M8 feature is simply to let the compiler know > that if it is completely impossible to make some memory object > aligned, then the cpu can handle this with special instructions. > > You still want the compiler to make the effort to align data when it > can because the accesses will be faster than if it used the unaligned > loads and stores. I don’t think the above is true. first, the compiler-time known misaligned memory access can always be emulated by aligned memory access ( by byte-size load/stores). then there will be no compiler-time known misaligned memory access left for the special misaligned ld/st insns. second, there are always overhead cost for the compiler-time effort to make the compiler-time known unaligned memory access as aligned memory access. (adding additional padding, or split the unaligned multi-bytes to single-byte load/store), all such overhead might be even bigger than the overhead of the special misaligned load/store itself. to decide which is better (to use software emulation or use hardware misaligned load/store insns), experiments might be needed to justify the performance impact. This set of change is to provide a way to use misaligned load/store insns to implement the compiler-time known unaligned memory access, -mno-misalign can be used to disable such behavior very easily if our performance data shows that misaligned load/store insns are slower than the current software emulation. Qing > > This is incredibly important for on-stack objects.
Re: [PATCH 1/1] sparc: support for -mmisalign in the SPARC M8
From: Qing Zhao Date: Thu, 3 Aug 2017 10:37:15 -0500 > all the special handling on STRICT_ALIGNMENT or > SLOW_UNALIGNMENT_ACCESS in these codes have the following common > logic: > > if the memory access is known to be not-aligned well during > compilation time, if the targeted platform does NOT support faster > unaligned memory access, the compiler will try to make the memory > access aligned well. Otherwise, if the targeted platform supports > faster unaligned memory access, it will leave the compiler-time > known not-aligned memory access as it, later the hardware support > will kicked in for these unaligned memory access. > > this behavior is consistent with the high level definition of > STRICT_ALIGNMENT. That's exactly the problem. What you want with this M8 feature is simply to let the compiler know that if it is completely impossible to make some memory object aligned, then the cpu can handle this with special instructions. You still want the compiler to make the effort to align data when it can because the accesses will be faster than if it used the unaligned loads and stores. This is incredibly important for on-stack objects.
Re: [PATCH 1/1] sparc: support for -mmisalign in the SPARC M8
To be more specified, when reading all the codes corresponding to “STRICT_ALIGNMENT” and “SLOW_UNALIGNMENT_ACCESS” in gcc (NOTE, SLOW_UNALIGNMENT_ACCESS is the same as STRICT_ALIGNMENT when it is NOT defined explicitly, this is the case for SPARC) We can get the following summary: all the special handling on STRICT_ALIGNMENT or SLOW_UNALIGNMENT_ACCESS in these codes have the following common logic: if the memory access is known to be not-aligned well during compilation time, if the targeted platform does NOT support faster unaligned memory access, the compiler will try to make the memory access aligned well. Otherwise, if the targeted platform supports faster unaligned memory access, it will leave the compiler-time known not-aligned memory access as it, later the hardware support will kicked in for these unaligned memory access. this behavior is consistent with the high level definition of STRICT_ALIGNMENT. And also consistent with the M8 misaligned support: if the target is NOT TARGET_MISALIGN, STRICT_ALIGNMENT is 1, all the compiler-time known misaligned memory accesses are adjusted to aligned memory access before RTL generation; on the other hand, if the target is TARGET_MISALIGN, STRICT_ALIGNMENT is 0, the compiler-time known misaligned memory accesses are NOT adjusted, after RTL generation, we will have compiler-time known misaligned memory access, we can use the new misaligned ld/st hardware insns to support these compiler-time known misaligned memory access. hope this is clear. thanks. Qing >> >> Why don't you read the code rather than just relying upon what >> high level description is given by the documentation instead? > > I read the codes before making the change, that’s the reason I ask you to > specify clearly the bad side effect that I didn’t considered yet. > > thanks. > > Qing
Re: [PATCH 1/1] sparc: support for -mmisalign in the SPARC M8
> On Aug 2, 2017, at 6:17 PM, David Miller wrote: > > From: Qing Zhao > Date: Wed, 2 Aug 2017 14:41:51 -0500 > >> so, could you please specify what kind of side effects will have >> when set STRICT_ALIGNMENT to true on TARGET_MISALIGN? > > Why don't you read the code rather than just relying upon what > high level description is given by the documentation instead? I read the codes before making the change, that’s the reason I ask you to specify clearly the bad side effect that I didn’t considered yet. thanks. Qing > > Thanks.
Re: [PATCH 1/1] sparc: support for -mmisalign in the SPARC M8
From: Qing Zhao Date: Wed, 2 Aug 2017 14:41:51 -0500 > so, could you please specify what kind of side effects will have > when set STRICT_ALIGNMENT to true on TARGET_MISALIGN? Why don't you read the code rather than just relying upon what high level description is given by the documentation instead? Thanks.
Re: [PATCH 1/1] sparc: support for -mmisalign in the SPARC M8
Hi, David, thanks a lot for your comment. see my reply below > STRICT_ALIGNMENT has a lot of implications. from the definition of STRICT_ALIGNMENT: /* Set this nonzero if move instructions will actually fail to work when given unaligned data. */ #define STRICT_ALIGNMENT 1 for MISALIGN_TARGET, it’s clear that move instructions will NOT fail to work when given unaligned data. so, it’s reasonable to set STRICT_ALIGNMENT to 0 for MISALIGN_TARGET. > > I think just because we happen to have misaligned loads and stores > available doesn't mean we want all of the side effects associated > with STRICT_ALIGNMENT being true. so, could you please specify what kind of side effects will have when = set STRICT_ALIGNMENT to true on TARGET_MISALIGN?=20 thanks a lot. Qing
Re: [PATCH 1/1] sparc: support for -mmisalign in the SPARC M8
From: qinzhao Date: Wed, 2 Aug 2017 10:27:51 -0500 > This patch adds support to GCC for the misaligned load/store > instructions introduced in the Oracle SPARC Architecture 2017 and > implemented by the SPARC M8 processor. > > A new command line option -mmisaligned is added, that activates the > usage of the new instructions. > > The SPARC backend is modified to use the misaligned load/store > instructions when loading/storing data from/to addresses that are > known to be misaligned at compile time (such as in packed structs). > > New tests are added to check that the proper instructions are used > when loading and storing from/to packed structs. > > The GCC manual is expanded to cover the new command-line option. STRICT_ALIGNMENT has a lot of implications. I think just because we happen to have misaligned loads and stores available doesn't mean we want all of the side effects associated with STRICT_ALIGNMENT being true.
[PATCH 1/1] sparc: support for -mmisalign in the SPARC M8
This patch adds support to GCC for the misaligned load/store
instructions introduced in the Oracle SPARC Architecture 2017 and
implemented by the SPARC M8 processor.
A new command line option -mmisaligned is added, that activates the
usage of the new instructions.
The SPARC backend is modified to use the misaligned load/store
instructions when loading/storing data from/to addresses that are
known to be misaligned at compile time (such as in packed structs).
New tests are added to check that the proper instructions are used
when loading and storing from/to packed structs.
The GCC manual is expanded to cover the new command-line option.
gcc/ChangeLog:
* config/sparc/constraints.md: New constraint B for memory
references whose addresses are misaligned.
* config/sparc/m8.md: New insn reservation for misaligned
load/store.
* config/sparc/sparc-protos.h (memory_is_misaligned): New.
* config/sparc/sparc.c (dump_target_flag_bits): Dump
MASK_MISALIGN.
(sparc_option_override): Honour MASK_MISALIGN, use command-line
option explicitly specified target_flags to control
target_flags.
(RTX_OK_FOR_OFFSET_P): For TARGET_MISALIGN treat 10-bits as
legal IMM.
(sparc_legitimate_address_p): Prohibit LO_SUM+IMM for
TARGET_MISALIGN.
(memory_is_misaligned): New
* config/sparc/sparc.h (STRICT_ALIGNMENT): Set to
!(TARGET_MISALIGN)
* config/sparc/sparc.md (cpu_feature): Add new feature misalign
(enabled): Handle misalign.
(type): New insn type load_mis, store_mis, fpload_mis,
fpstore_mis.
("*movhi_insn"): Add new alternatives for misaligned memory
accesses to use M8 misaligned load/store insns,update
corresponding attributes.
("*movsi_insn"): Likewise.
("*movdi_insn_sp32"): Likewise.
("*movdi_insn_sp64"): Likewise.
("*movsf_insn"): Likewise.
("*movdf_insn_sp32"): Likewise.
("*movdf_insn_sp64"): Likewise.
("*mov_insn"): Likewise.
("*mov_insn_sp64"): Likewise.
("*mov_insn_sp32"): Likewise.
(define_split): DI "memory_operand" from "const_zero_operand"
disable splitting for TARGET_MISALIGN.
(define_split): DF "memory_operand" from "const_zero_operand"
Likewise.
(define_split): VM64 "memory_operand" from "const_zero_operand"
Likewise.
* config/sparc/sparc.opt (mmisalign): New option.
* doc/invoke.texi (Option Summary): Document -mmisalign and
-mno-misalign.
(SPARC Optons): Likewise.
gcc/testsuite/ChangeLog:
* gcc.target/sparc/misalign-1.c: New test for misaligned ld/st.
* gcc.target/sparc/misalign-2.c: Likewise.
* gcc.target/sparc/misalign-3.c: Likewise.
* gcc.target/sparc/misalign-4.c: Likewise.
* gcc.target/sparc/misalign-5.c: Likewise.
* gcc.target/sparc/misalign-run-1.c: Likewise.
* gcc.target/sparc/misalign-run-2.c: Likewise.
* gcc.target/sparc/misalign-run-3.c: Likewise.
* lib/target-supports.exp (check_effective_target_misalign_hw):
New procedure.
---
gcc/config/sparc/constraints.md | 12 ++-
gcc/config/sparc/m8.md | 16 +-
gcc/config/sparc/sparc-protos.h |1 +
gcc/config/sparc/sparc.c| 60 +++-
gcc/config/sparc/sparc.h|5 +-
gcc/config/sparc/sparc.md | 183 +++
gcc/config/sparc/sparc.opt |4 +
gcc/doc/invoke.texi | 10 ++
gcc/testsuite/gcc.target/sparc/misalign-1.c | 45 ++
gcc/testsuite/gcc.target/sparc/misalign-2.c | 23 +++
gcc/testsuite/gcc.target/sparc/misalign-3.c | 42 +
gcc/testsuite/gcc.target/sparc/misalign-4.c | 23 +++
gcc/testsuite/gcc.target/sparc/misalign-5.c | 19 +++
gcc/testsuite/gcc.target/sparc/misalign-run-1.c | 34
gcc/testsuite/gcc.target/sparc/misalign-run-2.c | 23 +++
gcc/testsuite/gcc.target/sparc/misalign-run-3.c | 53 +++
gcc/testsuite/lib/target-supports.exp | 15 ++
17 files changed, 485 insertions(+), 83 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/sparc/misalign-1.c
create mode 100644 gcc/testsuite/gcc.target/sparc/misalign-2.c
create mode 100644 gcc/testsuite/gcc.target/sparc/misalign-3.c
create mode 100644 gcc/testsuite/gcc.target/sparc/misalign-4.c
create mode 100644 gcc/testsuite/gcc.target/sparc/misalign-5.c
create mode 100644 gcc/testsuite/gcc.target/sparc/misalign-run-1.c
create mode 100644 gcc/testsuite/gcc.target/sparc/misalign-run-2.c
create mode 100644 gcc/testsuite/gcc.target/sparc/misalign-run-3.c
diff --git a/gcc/config/sparc/constraints.md b/gcc/config/sparc/constraints.md
index cff5a61..ba15233 100644
---
