[COMMITTED] gcc: xtensa: fix pr95571 test for call0 ABI
gcc/testsuite/
* g++.target/xtensa/pr95571.C (__xtensa_libgcc_window_spill):
New definition.
---
gcc/testsuite/g++.target/xtensa/pr95571.C | 6 ++
1 file changed, 6 insertions(+)
diff --git a/gcc/testsuite/g++.target/xtensa/pr95571.C
b/gcc/testsuite/g++.target/xtensa/pr95571.C
index 59fe28528380..354e8cc660c7 100644
--- a/gcc/testsuite/g++.target/xtensa/pr95571.C
+++ b/gcc/testsuite/g++.target/xtensa/pr95571.C
@@ -3,6 +3,12 @@
extern "C" void abort(void);
extern "C" void __xtensa_libgcc_window_spill(void);
+#ifdef __XTENSA_CALL0_ABI__
+void __xtensa_libgcc_window_spill(void)
+{
+}
+#endif
+
static int call;
static int cnt;
--
2.30.2
[COMMITTED] xtensa: Improve constant synthesis for both integer and floating-point
From: Takayuki 'January June' Suwa
This patch revises the previous implementation of constant synthesis.
First, changed to use define_split machine description pattern and to run
after reload pass, in order not to interfere some optimizations such as
the loop invariant motion.
Second, not only integer but floating-point is subject to processing.
Third, several new synthesis patterns - when the constant cannot fit into
a "MOVI Ax, simm12" instruction, but:
I. can be represented as a power of two minus one (eg. 32767, 65535 or
0x7fffUL)
=> "MOVI(.N) Ax, -1" + "SRLI Ax, Ax, 1 ... 31" (or "EXTUI")
II. is between -34816 and 34559
=> "MOVI(.N) Ax, -2048 ... 2047" + "ADDMI Ax, Ax, -32768 ... 32512"
III. (existing case) can fit into a signed 12-bit if the trailing zero bits
are stripped
=> "MOVI(.N) Ax, -2048 ... 2047" + "SLLI Ax, Ax, 1 ... 31"
The above sequences consist of 5 or 6 bytes and have latency of 2 clock cycles,
in contrast with "L32R Ax, " (3 bytes and one clock latency, but may
suffer additional one clock pipeline stall and implementation-specific
InstRAM/ROM access penalty) plus 4 bytes of constant value.
In addition, 3-instructions synthesis patterns (8 or 9 bytes, 3 clock latency)
are also provided when optimizing for speed and L32R instruction has
considerable access penalty:
IV. 2-instructions synthesis (any of I ... III) followed by
"SLLI Ax, Ax, 1 ... 31"
V. 2-instructions synthesis followed by either "ADDX[248] Ax, Ax, Ax"
or "SUBX8 Ax, Ax, Ax" (multiplying by 3, 5, 7 or 9)
gcc/ChangeLog:
* config/xtensa/xtensa-protos.h (xtensa_constantsynth):
New prototype.
* config/xtensa/xtensa.cc (xtensa_emit_constantsynth,
xtensa_constantsynth_2insn, xtensa_constantsynth_rtx_SLLI,
xtensa_constantsynth_rtx_ADDSUBX, xtensa_constantsynth):
New backend functions that process the abovementioned logic.
(xtensa_emit_move_sequence): Revert the previous changes.
* config/xtensa/xtensa.md: New split patterns for integer
and floating-point, as the frontend part.
gcc/testsuite/ChangeLog:
* gcc.target/xtensa/constsynth_2insns.c: New.
* gcc.target/xtensa/constsynth_3insns.c: Ditto.
* gcc.target/xtensa/constsynth_double.c: Ditto.
---
gcc/config/xtensa/xtensa-protos.h | 1 +
gcc/config/xtensa/xtensa.cc | 133 +++---
gcc/config/xtensa/xtensa.md | 50 +++
.../gcc.target/xtensa/constsynth_2insns.c | 44 ++
.../gcc.target/xtensa/constsynth_3insns.c | 24
.../gcc.target/xtensa/constsynth_double.c | 11 ++
6 files changed, 247 insertions(+), 16 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/xtensa/constsynth_2insns.c
create mode 100644 gcc/testsuite/gcc.target/xtensa/constsynth_3insns.c
create mode 100644 gcc/testsuite/gcc.target/xtensa/constsynth_double.c
diff --git a/gcc/config/xtensa/xtensa-protos.h
b/gcc/config/xtensa/xtensa-protos.h
index 30e4b54394a9..c2fd750cd3ac 100644
--- a/gcc/config/xtensa/xtensa-protos.h
+++ b/gcc/config/xtensa/xtensa-protos.h
@@ -44,6 +44,7 @@ extern int xtensa_expand_block_move (rtx *);
extern int xtensa_expand_block_set_unrolled_loop (rtx *);
extern int xtensa_expand_block_set_small_loop (rtx *);
extern void xtensa_split_operand_pair (rtx *, machine_mode);
+extern int xtensa_constantsynth (rtx, HOST_WIDE_INT);
extern int xtensa_emit_move_sequence (rtx *, machine_mode);
extern rtx xtensa_copy_incoming_a7 (rtx);
extern void xtensa_expand_nonlocal_goto (rtx *);
diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index 597a36e1a973..3477e983592a 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -1037,6 +1037,123 @@ xtensa_split_operand_pair (rtx operands[4],
machine_mode mode)
}
+/* Try to emit insns to load srcval (that cannot fit into signed 12-bit)
+ into dst with synthesizing a such constant value from a sequence of
+ load-immediate / arithmetic ones, instead of a L32R instruction
+ (plus a constant in litpool). */
+
+static void
+xtensa_emit_constantsynth (rtx dst, enum rtx_code code,
+ HOST_WIDE_INT imm0, HOST_WIDE_INT imm1,
+ rtx (*gen_op)(rtx, HOST_WIDE_INT),
+ HOST_WIDE_INT imm2)
+{
+ gcc_assert (REG_P (dst));
+ emit_move_insn (dst, GEN_INT (imm0));
+ emit_move_insn (dst, gen_rtx_fmt_ee (code, SImode,
+ dst, GEN_INT (imm1)));
+ if (gen_op)
+emit_move_insn (dst, gen_op (dst, imm2));
+}
+
+static int
+xtensa_constantsynth_2insn (rtx dst, HOST_WIDE_INT srcval,
+ rtx (*gen_op)(rtx, HOST_WIDE_INT),
+ HOST_WIDE_INT op_imm)
+{
+ int shift = exact_log2 (srcval + 1);
+
+ if (IN_RANGE (shift, 1, 31))
+{
+ xtensa_emit_constantsynth (dst, LSHIFTRT, -1, 32 - shift,
+
[COMMITTED] xtensa: Consider the Loop Option when setmemsi is expanded to small loop
From: Takayuki 'January June' Suwa
Now apply to almost any size of aligned block under such circumstances.
gcc/ChangeLog:
* config/xtensa/xtensa.cc (xtensa_expand_block_set_small_loop):
Pass through the block length / loop count conditions if
zero-overhead looping is configured and active,
---
gcc/config/xtensa/xtensa.cc | 71 ++---
1 file changed, 50 insertions(+), 21 deletions(-)
diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index c7b54babc370..bc3330f836f3 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -1483,7 +1483,7 @@ xtensa_expand_block_set_unrolled_loop (rtx *operands)
int
xtensa_expand_block_set_small_loop (rtx *operands)
{
- HOST_WIDE_INT bytes, value, align;
+ HOST_WIDE_INT bytes, value, align, count;
int expand_len, funccall_len;
rtx x, dst, end, reg;
machine_mode unit_mode;
@@ -1503,17 +1503,25 @@ xtensa_expand_block_set_small_loop (rtx *operands)
/* Totally-aligned block only. */
if (bytes % align != 0)
return 0;
+ count = bytes / align;
- /* If 4-byte aligned, small loop substitution is almost optimal, thus
- limited to only offset to the end address for ADDI/ADDMI instruction. */
- if (align == 4
- && ! (bytes <= 127 || (bytes <= 32512 && bytes % 256 == 0)))
-return 0;
+ /* If the Loop Option (zero-overhead looping) is configured and active,
+ almost no restrictions about the length of the block. */
+ if (! (TARGET_LOOPS && optimize))
+{
+ /* If 4-byte aligned, small loop substitution is almost optimal,
+thus limited to only offset to the end address for ADDI/ADDMI
+instruction. */
+ if (align == 4
+ && ! (bytes <= 127 || (bytes <= 32512 && bytes % 256 == 0)))
+ return 0;
- /* If no 4-byte aligned, loop count should be treated as the constraint. */
- if (align != 4
- && bytes / align > ((optimize > 1 && !optimize_size) ? 8 : 15))
-return 0;
+ /* If no 4-byte aligned, loop count should be treated as the
+constraint. */
+ if (align != 4
+ && count > ((optimize > 1 && !optimize_size) ? 8 : 15))
+ return 0;
+}
/* Insn expansion: holding the init value.
Either MOV(.N) or L32R w/litpool. */
@@ -1523,16 +1531,33 @@ xtensa_expand_block_set_small_loop (rtx *operands)
expand_len = TARGET_DENSITY ? 2 : 3;
else
expand_len = 3 + 4;
- /* Insn expansion: Either ADDI(.N) or ADDMI for the end address. */
- expand_len += bytes > 127 ? 3
- : (TARGET_DENSITY && bytes <= 15) ? 2 : 3;
-
- /* Insn expansion: the loop body and branch instruction.
- For store, one of S8I, S16I or S32I(.N).
- For advance, ADDI(.N).
- For branch, BNE. */
- expand_len += (TARGET_DENSITY && align == 4 ? 2 : 3)
- + (TARGET_DENSITY ? 2 : 3) + 3;
+ if (TARGET_LOOPS && optimize) /* zero-overhead looping */
+{
+ /* Insn translation: Either MOV(.N) or L32R w/litpool for the
+loop count. */
+ expand_len += xtensa_simm12b (count) ? xtensa_sizeof_MOVI (count)
+ : 3 + 4;
+ /* Insn translation: LOOP, the zero-overhead looping setup
+instruction. */
+ expand_len += 3;
+ /* Insn expansion: the loop body instructions.
+ For store, one of S8I, S16I or S32I(.N).
+ For advance, ADDI(.N). */
+ expand_len += (TARGET_DENSITY && align == 4 ? 2 : 3)
+ + (TARGET_DENSITY ? 2 : 3);
+}
+ else /* NO zero-overhead looping */
+{
+ /* Insn expansion: Either ADDI(.N) or ADDMI for the end address. */
+ expand_len += bytes > 127 ? 3
+ : (TARGET_DENSITY && bytes <= 15) ? 2 : 3;
+ /* Insn expansion: the loop body and branch instruction.
+ For store, one of S8I, S16I or S32I(.N).
+ For advance, ADDI(.N).
+ For branch, BNE. */
+ expand_len += (TARGET_DENSITY && align == 4 ? 2 : 3)
+ + (TARGET_DENSITY ? 2 : 3) + 3;
+}
/* Function call: preparing two arguments. */
funccall_len = xtensa_sizeof_MOVI (value);
@@ -1555,7 +1580,11 @@ xtensa_expand_block_set_small_loop (rtx *operands)
dst = gen_reg_rtx (SImode);
emit_move_insn (dst, x);
end = gen_reg_rtx (SImode);
- emit_insn (gen_addsi3 (end, dst, operands[1] /* the length */));
+ if (TARGET_LOOPS && optimize)
+x = force_reg (SImode, operands[1] /* the length */);
+ else
+x = operands[1];
+ emit_insn (gen_addsi3 (end, dst, x));
switch (align)
{
case 1:
--
2.30.2
Re: [PATCH 3/4] xtensa: Improve instruction cost estimation and suggestion
On Thu, Jun 9, 2022 at 9:26 PM Takayuki 'January June' Suwa wrote: > > This patch implements a new target-specific relative RTL insn cost function > because of suboptimal cost estimation by default, and fixes several "length" > insn attributes (related to the cost estimation). > > And also introduces a new machine-dependent option "-mextra-l32r-costs=" > that tells implementation-specific InstRAM/ROM access penalty for L32R > instruction to the compiler (in clock-cycle units, 0 by default). > > gcc/ChangeLog: > > * config/xtensa/xtensa.cc (xtensa_rtx_costs): Correct wrong case > for ABS and NEG, add missing case for BSWAP and CLRSB, and > double the costs for integer divisions using libfuncs if > optimizing for speed, in order to take advantage of fast constant > division by multiplication. > (TARGET_INSN_COST): New macro definition. > (xtensa_is_insn_L32R_p, xtensa_insn_cost): New functions for > calculating relative costs of a RTL insns, for both of speed and > size. > * config/xtensa/xtensa.md (return, nop, trap): Correct values of > the attribute "length" that depends on TARGET_DENSITY. > (define_asm_attributes, blockage, frame_blockage): Add missing > attributes. > * config/xtensa/xtensa.opt (-mextra-l32r-costs=): New machine- > dependent option, however, preparatory work for now. > --- > gcc/config/xtensa/xtensa.cc | 116 --- > gcc/config/xtensa/xtensa.md | 29 ++--- > gcc/config/xtensa/xtensa.opt | 4 ++ > 3 files changed, 134 insertions(+), 15 deletions(-) Regtested for target=xtensa-linux-uclibc, no new regressions. Committed to master. -- Thanks. -- Max
Re: [PATCH 1/4] xtensa: Tweak some widen multiplications
On Thu, Jun 9, 2022 at 9:26 PM Takayuki 'January June' Suwa wrote: > > umulsidi3 is faster than umuldi3 even if library call, and is also > prerequisite for fast constant division by multiplication. > > gcc/ChangeLog: > > * config/xtensa/xtensa.md (mulsidi3, umulsidi3): > Split into individual signedness, in order to use libcall > "__umulsidi3" but not the other. > (mulhisi3): Merge into one by using code iterator. > (mulsidi3, mulhisi3, umulhisi3): Remove. > --- > gcc/config/xtensa/xtensa.md | 56 + > 1 file changed, 32 insertions(+), 24 deletions(-) Regtested for target=xtensa-linux-uclibc, no new regressions. Committed to master. -- Thanks. -- Max
Re: [PATCH] Fix PR target/104871 (macosx-version-min wrong for macOS >= Big Sur (darwin20))
Hi Simon,
> On 11 Jun 2022, at 20:23, Simon Wright wrote:
>
> On 11 Jun 2022, at 11:37, Iain Sandoe wrote:
>>
>> Hi Simon,
>>
>> thanks for the patch.
>>
>>> On 11 Jun 2022, at 10:17, Simon Wright wrote:
>>>
>>> (resent with correct address for Iain)
>>>
>>> This is the same sort of problem as in PR80204: at present, GCC 11 & 12
>>> assume that if the
>>> OS version is >= 20, the compiler should see --mmacosx-version-min={major -
>>> 9}.{minor -1}.0,
>>> e.g. for OS version 21.3.0 that would be 12.2.0 (the linker sees
>>> -macosx-version-min, same
>>> arguments).
>>>
>>> However, the native compiler clang treats 21.3.0 as 12.0.0: the compiler
>>> sees
>>> -triple x86_64-apple-macosx12.0.0
>>> and the linker sees
>>> -platform_version macos 12.0.0
>>> the result of which is that linking an object file built with clang and one
>>> built with gcc gives e.g.
>>>
>>> ld: warning: object file (null.o) was built for newer macOS version (12.2)
>>> than being linked (12.0)
>>>
>>> I propose the following patch, which works fine for me (darwin 21.3.0).
>>
>> this LGTM - just need to sort out a couple of nits and an admin point.
>>
>> FWIW; the following are honoured in preserving the minor version (so we
>> still have scope for
>> mismatches if some objects are built this way and others picking up the
>> kernel version) ..
>>
>> clang -target x86_64-apple-macosx11.3 …
>> clang -mmacosx-version-min=11.3 …
>> MACOSX_DEPLOYMENT_TARGET=11.3 clang … (although this seems on at least one
>> version
>> of xcodem to pass 12.3 to the linker.. hmmm).
>
> Something on the lines of "the native compiler clang treats 21.3.0 as 12.0.0
> (unless overridden by e.g.
> MACOSX_DEPLOYMENT_TARGET=11.3 )"?
>
> I did see in the otool -l report on a gcc 12.1.0 executable generated as
> above (Darwin 21.5.0)
>
> cmd LC_BUILD_VERSION
> cmdsize 32
> platform 1
> minos 11.3
> sdk 10.17
>
> — don’t know where the 10.17 comes from,
That’s the version of the SDK in use (it’s embedded in the plist of the SDK
except in the very early ones).
The full -platform_version command has a space for the SDK, perhaps ld64 looks
it up these days if not
supplied on the command line. Odd that it’s named 10.17 instead of 11.x
(the latest sources for ld64 are quite old now, so can’t check what newer
versions of the linker are doing).
> still there even without MACOSX_DEPLOYMENT_TARGET.
> The SDK was Xcode 13.4.1. I also have CLT 13.4.0.0.1.1651278267. clang tells
> ld
> "-platform_version macos 11.3.0 12.3", gcc just says "-macosx_version_min
> 11.3".
GCC does not implement the -platform_version command yet (we have a configure
scan for it but
not needed to use it so far) - not sure if we really want to get into parsing
plist files to find the SDK version
(or get tied to using more tools out of our control).
>> I guess you do not have commit access?
>> if you do not have an FSF assignment for copyright, are you OK to sign this
>> off using the DCO?
>>
>> https://gcc.gnu.org/dco.html
>
> No commit access, but FSF assignment RT:1016382. Do I need to say this in the
> patch email somewhere?
no, that’s fine - we just need one (assignment) or the other (DCO).
>> for furture reference, please check that patches conform to GCC coding style
>> (this one has some
>> whitespace glitches)
>
> I don’t see the whitespace glitches? (I have missed a period after ld in the
> second comment)
sets of 8 leading spaces should be tabs.
the source tree has some checking tools for commits (in contrib/ ), which can
be useful.
It’s also quite handy to have the entire commit with the commit message in
one’s local repo and then
just do “git format-patch -1 xxx” to get the patch for posting (but, of
course, everyone has
their own favourite git workflow).
OK, thanks, I think I’ve got everything needed to get this applied, there’s no
need to re-issue, I’ll tweak
the commit message and the whitespace.
Iain
>
>>
>> thanks,
>> Iain
>>
>>
>>> gcc/ChangeLog:
>>>
>>> 2022-06-02 Simon Wright
>>>
>>> PR target/104871
>>> * config/darwin-driver.cc (darwin_find_version_from_kernel): If the OS
>>> version is
>>> 20 (macOS 11) or greater, report the minor version and the patch level as 0
>>> to match Apple clang’s behaviour.
>>>
>>>
Re: [PATCH] x86: Require AVX for F16C and VAES
On Fri, Jun 10, 2022 at 8:28 PM H.J. Lu wrote: > > Since F16C and VAES are only usable with AVX, require AVX for F16C and > VAES. > > OK for master and release branches? > > Thanks. > > H.J. > --- > libgcc/105920 > * common/config/i386/cpuinfo.h (get_available_features): Require > AVX for F16C and VAES. OK. Thanks, Uros. > --- > gcc/common/config/i386/cpuinfo.h | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/gcc/common/config/i386/cpuinfo.h > b/gcc/common/config/i386/cpuinfo.h > index adc02bc3d98..bbced8a23b9 100644 > --- a/gcc/common/config/i386/cpuinfo.h > +++ b/gcc/common/config/i386/cpuinfo.h > @@ -651,8 +651,6 @@ get_available_features (struct __processor_model > *cpu_model, > set_feature (FEATURE_MOVBE); >if (ecx & bit_AES) > set_feature (FEATURE_AES); > - if (ecx & bit_F16C) > -set_feature (FEATURE_F16C); >if (ecx & bit_RDRND) > set_feature (FEATURE_RDRND); >if (ecx & bit_XSAVE) > @@ -663,6 +661,8 @@ get_available_features (struct __processor_model > *cpu_model, > set_feature (FEATURE_AVX); >if (ecx & bit_FMA) > set_feature (FEATURE_FMA); > + if (ecx & bit_F16C) > + set_feature (FEATURE_F16C); > } > >/* Get Advanced Features at level 7 (eax = 7, ecx = 0/1). */ > @@ -683,6 +683,8 @@ get_available_features (struct __processor_model > *cpu_model, > set_feature (FEATURE_AVX2); > if (ecx & bit_VPCLMULQDQ) > set_feature (FEATURE_VPCLMULQDQ); > + if (ecx & bit_VAES) > + set_feature (FEATURE_VAES); > } >if (ebx & bit_BMI2) > set_feature (FEATURE_BMI2); > @@ -705,8 +707,6 @@ get_available_features (struct __processor_model > *cpu_model, > set_feature (FEATURE_PKU); >if (ecx & bit_RDPID) > set_feature (FEATURE_RDPID); > - if (ecx & bit_VAES) > - set_feature (FEATURE_VAES); >if (ecx & bit_GFNI) > set_feature (FEATURE_GFNI); >if (ecx & bit_MOVDIRI) > -- > 2.36.1 >
Re: [PATCH] Fix PR target/104871 (macosx-version-min wrong for macOS >= Big Sur (darwin20))
On 11 Jun 2022, at 11:37, Iain Sandoe wrote:
>
> Hi Simon,
>
> thanks for the patch.
>
>> On 11 Jun 2022, at 10:17, Simon Wright wrote:
>>
>> (resent with correct address for Iain)
>>
>> This is the same sort of problem as in PR80204: at present, GCC 11 & 12
>> assume that if the
>> OS version is >= 20, the compiler should see --mmacosx-version-min={major -
>> 9}.{minor -1}.0,
>> e.g. for OS version 21.3.0 that would be 12.2.0 (the linker sees
>> -macosx-version-min, same
>> arguments).
>>
>> However, the native compiler clang treats 21.3.0 as 12.0.0: the compiler sees
>> -triple x86_64-apple-macosx12.0.0
>> and the linker sees
>> -platform_version macos 12.0.0
>> the result of which is that linking an object file built with clang and one
>> built with gcc gives e.g.
>>
>> ld: warning: object file (null.o) was built for newer macOS version (12.2)
>> than being linked (12.0)
>>
>> I propose the following patch, which works fine for me (darwin 21.3.0).
>
> this LGTM - just need to sort out a couple of nits and an admin point.
>
> FWIW; the following are honoured in preserving the minor version (so we still
> have scope for
> mismatches if some objects are built this way and others picking up the
> kernel version) ..
>
> clang -target x86_64-apple-macosx11.3 …
> clang -mmacosx-version-min=11.3 …
> MACOSX_DEPLOYMENT_TARGET=11.3 clang … (although this seems on at least one
> version
> of xcodem to pass 12.3 to the linker.. hmmm).
Something on the lines of "the native compiler clang treats 21.3.0 as 12.0.0
(unless overridden by e.g.
MACOSX_DEPLOYMENT_TARGET=11.3 )"?
I did see in the otool -l report on a gcc 12.1.0 executable generated as above
(Darwin 21.5.0)
cmd LC_BUILD_VERSION
cmdsize 32
platform 1
minos 11.3
sdk 10.17
— don’t know where the 10.17 comes from, still there even without
MACOSX_DEPLOYMENT_TARGET.
The SDK was Xcode 13.4.1. I also have CLT 13.4.0.0.1.1651278267. clang tells ld
"-platform_version macos 11.3.0 12.3", gcc just says "-macosx_version_min 11.3".
> I guess you do not have commit access?
> if you do not have an FSF assignment for copyright, are you OK to sign this
> off using the DCO?
>
> https://gcc.gnu.org/dco.html
No commit access, but FSF assignment RT:1016382. Do I need to say this in the
patch email somewhere?
> for furture reference, please check that patches conform to GCC coding style
> (this one has some
> whitespace glitches)
I don’t see the whitespace glitches? (I have missed a period after ld in the
second comment)
>
> thanks,
> Iain
>
>
>> gcc/ChangeLog:
>>
>> 2022-06-02 Simon Wright mailto:si...@pushface.org>>
>>
>> PR target/104871
>> * config/darwin-driver.cc
Modula-2: merge followup (brief update on the progress of the new linking implementation)
Here is a brief synopsis of the new linking implementation. Completed: runtime module dependency resolution, IR scaffold and IR runtime dependency graph and the compiler driver. Todo: per module ctors. The proposed road map: once helloworld links using the new scheme I plan to git push the updates. Thereafter debug, test, polish and then generate new patch sets. Feel free to make suggestions though, regards, Gaius
Re: [PING][PATCH][WIP] have configure probe prefix for gmp/mpfr/mpc [PR44425]
On Fri, Jun 10, 2022 at 7:22 AM Xi Ruoyao wrote:
>
> On Thu, 2022-06-09 at 16:04 -0400, Eric Gallager via Gcc-patches wrote:
> > Hi, I'd like to ping this patch:
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596126.html
> > (cc-ing the build machinery maintainers listed in MAINTAINERS this
> > time)
> >
> > On Thu, Jun 2, 2022 at 11:53 AM Eric Gallager
> > wrote:
> > >
> > > So, I'm working on fixing PR bootstrap/44425, and have this patch to
> > > have the top-level configure script check in the value passed to
> > > `--prefix=` when looking for gmp/mpfr/mpc. It "works" (in that
> > > configuring with just `--prefix=` and none of
> > > `--with-gmp=`/`--with-mpfr=`/`--with-mpc=` now works where it failed
> > > before), but unfortunately it results in a bunch of duplicated
> > > `-I`/`-L` flags stuck in ${gmplibs} and ${gmpinc}... is that
> > > acceptable or should I try another approach?
> > > Eric
>
> A patch should not edit configure directly. configure.ac should be
> edited and configure should be regenerated from it.
>
That is precisely what the patch does: it edits configure.ac and
regenerates configure from it.
> --
> Xi Ruoyao
> School of Aerospace Science and Technology, Xidian University
Re: [PATCH] Mips: Enable asynchronous unwind tables with both ASAN and TSAN
> Well, so should we add TSAN_SUPPORTED=yes for MIPS64 in > libsanitizer/configure.tgt first? I'll try this on my MIPS64 in a few > days. Just tried TSAN_SUPPORTED=yes with asynchronous unwind tables enabled, but I got some strange test failures for tls_race.c: FAIL: c-c++-common/tsan/tls_race.c -O0 output pattern test Output was: ThreadSanitizer: CHECK failed: tsan_platform_linux.cpp:452 "((thr_end)) <= ((tls_addr + tls_size))" (0xffec35f8c0, 0xffec35f784) (tid=748216) #0 __tsan::CheckUnwind() ../../../../gcc/libsanitizer/tsan/tsan_rtl.cpp:627 (libtsan.so.2+0xa30ec) #1 __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_termination.cpp:86 (libtsan.so.2+0xeb8cc) #2 __tsan::ImitateTlsWrite(__tsan::ThreadState*, unsigned long, unsigned long) ../../../../gcc/libsanitizer/tsan/tsan_platform_linux.cpp:452 (libtsan.so.2+0xa0cac) #3 __tsan::ThreadStart(__tsan::ThreadState*, unsigned int, unsigned long long, __sanitizer::ThreadType) ../../../../gcc/libsanitizer/tsan/tsan_rtl_thread.cpp:197 (libtsan.so.2+0xc0e88) #4 __tsan_thread_start_func ../../../../gcc/libsanitizer/tsan/tsan_interceptors_posix.cpp:1009 (libtsan.so.2+0x3e5dc) #5 start_thread /sources/glibc-2.35/nptl/pthread_create.c:442 (libc.so.6+0xc75f4) I've tried to diagnose the root cause but failed. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: [PATCH] Fix PR target/104871 (macosx-version-min wrong for macOS >= Big Sur (darwin20))
Hi Simon,
thanks for the patch.
> On 11 Jun 2022, at 10:17, Simon Wright wrote:
>
> (resent with correct address for Iain)
>
> This is the same sort of problem as in PR80204: at present, GCC 11 & 12
> assume that if the
> OS version is >= 20, the compiler should see --mmacosx-version-min={major -
> 9}.{minor -1}.0,
> e.g. for OS version 21.3.0 that would be 12.2.0 (the linker sees
> -macosx-version-min, same
> arguments).
>
> However, the native compiler clang treats 21.3.0 as 12.0.0: the compiler sees
> -triple x86_64-apple-macosx12.0.0
> and the linker sees
> -platform_version macos 12.0.0
> the result of which is that linking an object file built with clang and one
> built with gcc gives e.g.
>
> ld: warning: object file (null.o) was built for newer macOS version (12.2)
> than being linked (12.0)
>
> I propose the following patch, which works fine for me (darwin 21.3.0).
this LGTM - just need to sort out a couple of nits and an admin point.
FWIW; the following are honoured in preserving the minor version (so we still
have scope for
mismatches if some objects are built this way and others picking up the kernel
version) ..
clang -target x86_64-apple-macosx11.3 …
clang -mmacosx-version-min=11.3 …
MACOSX_DEPLOYMENT_TARGET=11.3 clang … (although this seems on at least one
version
of xcodem to pass 12.3 to the linker.. hmmm).
I guess you do not have commit access?
if you do not have an FSF assignment for copyright, are you OK to sign this off
using the DCO?
https://gcc.gnu.org/dco.html
for furture reference, please check that patches conform to GCC coding style
(this one has some
whitespace glitches)
thanks,
Iain
> gcc/ChangeLog:
>
> 2022-06-02 Simon Wright
>
> PR target/104871
> * config/darwin-driver.cc (darwin_find_version_from_kernel): If the OS
> version is
> 20 (macOS 11) or greater, report the minor version and the patch
> level as 0
> to match Apple clang’s behaviour.
>
>
[PATCH v3 4/4] xtensa: Improve constant synthesis for both integer and floating-point
thanks for your report.
On 2022/06/11 18:05, Max Filippov wrote:
It prints
(symbol_ref/f:SI ("*.LC1") [flags 0x2] )
ah, i understand it... that is Pmode (synonym of SImode) of a memory
address that points to 'u.f'.
thus, the correct handling is to fail the split pattern.
---
gcc/config/xtensa/xtensa-protos.h | 1 +
gcc/config/xtensa/xtensa.cc | 133 +++---
gcc/config/xtensa/xtensa.md | 50 +++
.../gcc.target/xtensa/constsynth_2insns.c | 44 ++
.../gcc.target/xtensa/constsynth_3insns.c | 24
.../gcc.target/xtensa/constsynth_double.c | 11 ++
6 files changed, 247 insertions(+), 16 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/xtensa/constsynth_2insns.c
create mode 100644 gcc/testsuite/gcc.target/xtensa/constsynth_3insns.c
create mode 100644 gcc/testsuite/gcc.target/xtensa/constsynth_double.c
diff --git a/gcc/config/xtensa/xtensa-protos.h
b/gcc/config/xtensa/xtensa-protos.h
index 30e4b54394a..c2fd750cd3a 100644
--- a/gcc/config/xtensa/xtensa-protos.h
+++ b/gcc/config/xtensa/xtensa-protos.h
@@ -44,6 +44,7 @@ extern int xtensa_expand_block_move (rtx *);
extern int xtensa_expand_block_set_unrolled_loop (rtx *);
extern int xtensa_expand_block_set_small_loop (rtx *);
extern void xtensa_split_operand_pair (rtx *, machine_mode);
+extern int xtensa_constantsynth (rtx, HOST_WIDE_INT);
extern int xtensa_emit_move_sequence (rtx *, machine_mode);
extern rtx xtensa_copy_incoming_a7 (rtx);
extern void xtensa_expand_nonlocal_goto (rtx *);
diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index 597a36e1a97..3477e983592 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -1037,6 +1037,123 @@ xtensa_split_operand_pair (rtx operands[4],
machine_mode mode)
}
+/* Try to emit insns to load srcval (that cannot fit into signed 12-bit)
+ into dst with synthesizing a such constant value from a sequence of
+ load-immediate / arithmetic ones, instead of a L32R instruction
+ (plus a constant in litpool). */
+
+static void
+xtensa_emit_constantsynth (rtx dst, enum rtx_code code,
+ HOST_WIDE_INT imm0, HOST_WIDE_INT imm1,
+ rtx (*gen_op)(rtx, HOST_WIDE_INT),
+ HOST_WIDE_INT imm2)
+{
+ gcc_assert (REG_P (dst));
+ emit_move_insn (dst, GEN_INT (imm0));
+ emit_move_insn (dst, gen_rtx_fmt_ee (code, SImode,
+ dst, GEN_INT (imm1)));
+ if (gen_op)
+emit_move_insn (dst, gen_op (dst, imm2));
+}
+
+static int
+xtensa_constantsynth_2insn (rtx dst, HOST_WIDE_INT srcval,
+ rtx (*gen_op)(rtx, HOST_WIDE_INT),
+ HOST_WIDE_INT op_imm)
+{
+ int shift = exact_log2 (srcval + 1);
+
+ if (IN_RANGE (shift, 1, 31))
+{
+ xtensa_emit_constantsynth (dst, LSHIFTRT, -1, 32 - shift,
+gen_op, op_imm);
+ return 1;
+}
+
+ if (IN_RANGE (srcval, (-2048 - 32768), (2047 + 32512)))
+{
+ HOST_WIDE_INT imm0, imm1;
+
+ if (srcval < -32768)
+ imm1 = -32768;
+ else if (srcval > 32512)
+ imm1 = 32512;
+ else
+ imm1 = srcval & ~255;
+ imm0 = srcval - imm1;
+ if (TARGET_DENSITY && imm1 < 32512 && IN_RANGE (imm0, 224, 255))
+ imm0 -= 256, imm1 += 256;
+ xtensa_emit_constantsynth (dst, PLUS, imm0, imm1, gen_op, op_imm);
+ return 1;
+}
+
+ shift = ctz_hwi (srcval);
+ if (xtensa_simm12b (srcval >> shift))
+{
+ xtensa_emit_constantsynth (dst, ASHIFT, srcval >> shift, shift,
+gen_op, op_imm);
+ return 1;
+}
+
+ return 0;
+}
+
+static rtx
+xtensa_constantsynth_rtx_SLLI (rtx reg, HOST_WIDE_INT imm)
+{
+ return gen_rtx_ASHIFT (SImode, reg, GEN_INT (imm));
+}
+
+static rtx
+xtensa_constantsynth_rtx_ADDSUBX (rtx reg, HOST_WIDE_INT imm)
+{
+ return imm == 7
+? gen_rtx_MINUS (SImode, gen_rtx_ASHIFT (SImode, reg, GEN_INT (3)),
+ reg)
+: gen_rtx_PLUS (SImode, gen_rtx_ASHIFT (SImode, reg,
+GEN_INT (floor_log2 (imm -
1))),
+reg);
+}
+
+int
+xtensa_constantsynth (rtx dst, HOST_WIDE_INT srcval)
+{
+ /* No need for synthesizing for what fits into MOVI instruction. */
+ if (xtensa_simm12b (srcval))
+return 0;
+
+ /* 2-insns substitution. */
+ if ((optimize_size || (optimize && xtensa_extra_l32r_costs >= 1))
+ && xtensa_constantsynth_2insn (dst, srcval, NULL, 0))
+return 1;
+
+ /* 3-insns substitution. */
+ if (optimize > 1 && !optimize_size && xtensa_extra_l32r_costs >= 2)
+{
+ int shift, divisor;
+
+ /* 2-insns substitution followed by SLLI. */
+ shift = ctz_hwi (srcval);
+ if (IN_RANGE (shift, 1, 31) &&
+ xtensa_constantsynth_2insn (dst, srcval >> shift,
+
[PATCH] Fix PR target/104871 (macosx-version-min wrong for macOS >= Big Sur (darwin20))
(resent with correct address for Iain)
This is the same sort of problem as in PR80204: at present, GCC 11 & 12 assume
that if the
OS version is >= 20, the compiler should see --mmacosx-version-min={major -
9}.{minor -1}.0,
e.g. for OS version 21.3.0 that would be 12.2.0 (the linker sees
-macosx-version-min, same
arguments).
However, the native compiler clang treats 21.3.0 as 12.0.0: the compiler sees
-triple x86_64-apple-macosx12.0.0
and the linker sees
-platform_version macos 12.0.0
the result of which is that linking an object file built with clang and one
built with gcc gives e.g.
ld: warning: object file (null.o) was built for newer macOS version (12.2)
than being linked (12.0)
I propose the following patch, which works fine for me (darwin 21.3.0).
gcc/ChangeLog:
2022-06-02 Simon Wright
PR target/104871
* config/darwin-driver.cc (darwin_find_version_from_kernel): If the OS
version is
20 (macOS 11) or greater, report the minor version and the patch
level as 0
to match Apple clang’s behaviour.
pr104871.diff
Description: Binary data
Re: [PATCH v2 4/4] xtensa: Improve constant synthesis for both integer and floating-point
On Sat, Jun 11, 2022 at 1:31 AM Takayuki 'January June' Suwa
wrote:
> > this change results in a bunch of ICEs in the tests like this:
> > during RTL pass: split2
> > gcc/gcc/testsuite/gcc.c-torture/compile/20120727-1.c: In function 'f':
> > gcc/gcc/testsuite/gcc.c-torture/compile/20120727-1.c:13:1: internal
> > compiler error: in gen_split_5, at config/xtensa/xtensa.md:1186
> [from config/xtensa/xtensa.md]
>if (GET_MODE (x) == SFmode)
> REAL_VALUE_TO_TARGET_SINGLE (*CONST_DOUBLE_REAL_VALUE (x), l[0]);
>else if (GET_MODE (x) == DFmode)
> REAL_VALUE_TO_TARGET_DOUBLE (*CONST_DOUBLE_REAL_VALUE (x), l);
>else
> gcc_unreachable (); // line 1186
>x = gen_rtx_REG (SImode, REGNO (operands[0]));
>
> umm, i don't know how 'XEXP (operands[1], 0)' can be neither SFmode nor
> DFmode...
> please tell me that test piece of code, and/or apply the below patch and
> reply what the compiler print to stderr:
>
> --- gcc/config/xtensa/xtensa.md
> +++ gcc/config/xtensa/xtensa.md
> @@ -1183,7 +1183,10 @@
> else if (GET_MODE (x) == DFmode)
> REAL_VALUE_TO_TARGET_DOUBLE (*CONST_DOUBLE_REAL_VALUE (x), l);
> else
> -gcc_unreachable ();
> +{
> + print_rtl_single (stderr, x);
> + gcc_unreachable ();
> +}
> x = gen_rtx_REG (SImode, REGNO (operands[0]));
> if (! xtensa_constantsynth (x, l[i]))
> emit_move_insn (x, GEN_INT (l[i]));
>
It prints
(symbol_ref/f:SI ("*.LC1") [flags 0x2] )
--
Thanks.
-- Max
Re: [PATCH v2 4/4] xtensa: Improve constant synthesis for both integer and floating-point
On Sat, Jun 11, 2022 at 1:31 AM Takayuki 'January June' Suwa wrote: > > this change results in a bunch of ICEs in the tests like this: > > during RTL pass: split2 > > gcc/gcc/testsuite/gcc.c-torture/compile/20120727-1.c: In function 'f': > > gcc/gcc/testsuite/gcc.c-torture/compile/20120727-1.c:13:1: internal > > compiler error: in gen_split_5, at config/xtensa/xtensa.md:1186 > [from config/xtensa/xtensa.md] >if (GET_MODE (x) == SFmode) > REAL_VALUE_TO_TARGET_SINGLE (*CONST_DOUBLE_REAL_VALUE (x), l[0]); >else if (GET_MODE (x) == DFmode) > REAL_VALUE_TO_TARGET_DOUBLE (*CONST_DOUBLE_REAL_VALUE (x), l); >else > gcc_unreachable (); // line 1186 >x = gen_rtx_REG (SImode, REGNO (operands[0])); > > umm, i don't know how 'XEXP (operands[1], 0)' can be neither SFmode nor > DFmode... > please tell me that test piece of code It is produced during make check-gcc by the following command line: /home/jcmvbkbc/ws/tensilica/gcc/builds/gcc-13-1039-g2c2987950301-windowed-be/gcc/xgcc -B/home/jcmvbkbc/ws/tensilica/gcc/builds/gcc-13-1039-g2c2987950301-windowed-be/gcc/ -mtext-section-literals -mlongcalls -fdiagnostics- plain-output -O1 -w -c -o 20120727-1.o /home/jcmvbkbc/ws/tensilica/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/20120727-1.c -- Thanks. -- Max
Re: [PATCH v2 4/4] xtensa: Improve constant synthesis for both integer and floating-point
On 2022/06/11 16:58, Max Filippov wrote:
Hi Suwa-san,
hi!
this change results in a bunch of ICEs in the tests like this:
during RTL pass: split2
gcc/gcc/testsuite/gcc.c-torture/compile/20120727-1.c: In function 'f':
gcc/gcc/testsuite/gcc.c-torture/compile/20120727-1.c:13:1: internal
compiler error: in gen_split_5, at config/xtensa/xtensa.md:1186
[from config/xtensa/xtensa.md]
if (GET_MODE (x) == SFmode)
REAL_VALUE_TO_TARGET_SINGLE (*CONST_DOUBLE_REAL_VALUE (x), l[0]);
else if (GET_MODE (x) == DFmode)
REAL_VALUE_TO_TARGET_DOUBLE (*CONST_DOUBLE_REAL_VALUE (x), l);
else
gcc_unreachable (); // line 1186
x = gen_rtx_REG (SImode, REGNO (operands[0]));
umm, i don't know how 'XEXP (operands[1], 0)' can be neither SFmode nor
DFmode...
please tell me that test piece of code, and/or apply the below patch and
reply what the compiler print to stderr:
--- gcc/config/xtensa/xtensa.md
+++ gcc/config/xtensa/xtensa.md
@@ -1183,7 +1183,10 @@
else if (GET_MODE (x) == DFmode)
REAL_VALUE_TO_TARGET_DOUBLE (*CONST_DOUBLE_REAL_VALUE (x), l);
else
-gcc_unreachable ();
+{
+ print_rtl_single (stderr, x);
+ gcc_unreachable ();
+}
x = gen_rtx_REG (SImode, REGNO (operands[0]));
if (! xtensa_constantsynth (x, l[i]))
emit_move_insn (x, GEN_INT (l[i]));
Re: [PATCH v2 4/4] xtensa: Improve constant synthesis for both integer and floating-point
Hi Suwa-san, On Fri, Jun 10, 2022 at 8:28 AM Takayuki 'January June' Suwa wrote: > > This patch revises the previous implementation of constant synthesis. > > First, changed to use define_split machine description pattern and to run > after reload pass, in order not to interfere some optimizations such as > the loop invariant motion. > > Second, not only integer but floating-point is subject to processing. > > Third, several new synthesis patterns - when the constant cannot fit into > a "MOVI Ax, simm12" instruction, but: > > I. can be represented as a power of two minus one (eg. 32767, 65535 or > 0x7fffUL) > => "MOVI(.N) Ax, -1" + "SRLI Ax, Ax, 1 ... 31" (or "EXTUI") > II. is between -34816 and 34559 > => "MOVI(.N) Ax, -2048 ... 2047" + "ADDMI Ax, Ax, -32768 ... 32512" > III. (existing case) can fit into a signed 12-bit if the trailing zero bits > are stripped > => "MOVI(.N) Ax, -2048 ... 2047" + "SLLI Ax, Ax, 1 ... 31" > > The above sequences consist of 5 or 6 bytes and have latency of 2 clock > cycles, > in contrast with "L32R Ax, " (3 bytes and one clock latency, > but may > suffer additional one clock pipeline stall and implementation-specific > InstRAM/ROM access penalty) plus 4 bytes of constant value. > > In addition, 3-instructions synthesis patterns (8 or 9 bytes, 3 clock > latency) > are also provided when optimizing for speed and L32R instruction has > considerable access penalty: > > IV. 2-instructions synthesis (any of I ... III) followed by > "SLLI Ax, Ax, 1 ... 31" > V. 2-instructions synthesis followed by either "ADDX[248] Ax, Ax, Ax" > or "SUBX8 Ax, Ax, Ax" (multiplying by 3, 5, 7 or 9) > > gcc/ChangeLog: > > * config/xtensa/xtensa-protos.h (xtensa_constantsynth): > New prototype. > * config/xtensa/xtensa.cc (xtensa_emit_constantsynth, > xtensa_constantsynth_2insn, xtensa_constantsynth_rtx_SLLI, > xtensa_constantsynth_rtx_ADDSUBX, xtensa_constantsynth): > New backend functions that process the abovementioned logic. > (xtensa_emit_move_sequence): Revert the previous changes. > * config/xtensa/xtensa.md: New split patterns for integer > and floating-point, as the frontend part. > > gcc/testsuite/ChangeLog: > > * gcc.target/xtensa/constsynth_2insns.c: New. > * gcc.target/xtensa/constsynth_3insns.c: Ditto. > * gcc.target/xtensa/constsynth_double.c: Ditto. > --- > gcc/config/xtensa/xtensa-protos.h | 1 + > gcc/config/xtensa/xtensa.cc | 133 +++--- > gcc/config/xtensa/xtensa.md | 50 +++ > .../gcc.target/xtensa/constsynth_2insns.c | 44 ++ > .../gcc.target/xtensa/constsynth_3insns.c | 24 > .../gcc.target/xtensa/constsynth_double.c | 11 ++ > 6 files changed, 247 insertions(+), 16 deletions(-) > create mode 100644 gcc/testsuite/gcc.target/xtensa/constsynth_2insns.c > create mode 100644 gcc/testsuite/gcc.target/xtensa/constsynth_3insns.c > create mode 100644 gcc/testsuite/gcc.target/xtensa/constsynth_double.c this change results in a bunch of ICEs in the tests like this: during RTL pass: split2 gcc/gcc/testsuite/gcc.c-torture/compile/20120727-1.c: In function 'f': gcc/gcc/testsuite/gcc.c-torture/compile/20120727-1.c:13:1: internal compiler error: in gen_split_5, at config/xtensa/xtensa.md:1186 0x7b6fdb gen_split_5(rtx_insn*, rtx_def**) gcc/gcc/config/xtensa/xtensa.md:1186 0xa8f927 try_split(rtx_def*, rtx_insn*, int) gcc/gcc/emit-rtl.cc:3795 0xde5fe9 split_insn gcc/gcc/recog.cc:3384 0xdecde7 split_all_insns() gcc/gcc/recog.cc:3488 0xdecea8 execute gcc/gcc/recog.cc:4406 -- Thanks. -- Max
