From: Andrew Pinski
Since match and simplify does not have all of the inverted
comparison patterns, it make sense to just have
phi-opt try to do the inversion and try match and simplify again.
OK? Bootstrapped and tested on x86_64-linux-gnu.
Thanks,
Andrew Pinski
gcc/ChangeLog
From: Andrew Pinski
HONOR_SIGNED_ZEROS, HONOR_SIGN_DEPENDENT_ROUNDING, and HONOR_SNANS all
have an overload for taking a tree type now, so we should do that instead.
OK? Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
PR middle-end/101237
* fold-const.c
be able to
copy the range info; this assumes the statements will define
the ssa name.
gcc/ChangeLog:
PR tree-optimization/101256
* dbgcnt.def (phiopt_edge_range): New counter.
* tree-ssa-phiopt.c (replace_phi_edge_with_variable):
Add optional sequence which will be
regressions.
gcc/ChangeLog:
* tree-ssa-phiopt.c (match_simplify_replacement):
Add early_p argument. Call gimple_simplify_phiopt
instead of gimple_simplify.
(tree_ssa_phiopt_worker): Update call to
match_simplify_replacement and allow unconditionally
ot creating ABS.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
PR tree-optimization/101039
* match.pd (A CMP 0 ? A : -A): New patterns.
* tree-ssa-phiopt.c (abs_replacement): Delete function.
(tree_ssa_phiopt_worker): Don't call abs_re
Hi Honza and All,
After more checks, I'm thinking these patches may still be useful.
For patch 1:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555871.html
This patch recalculates the loop's BB-count and could correct
some BB-count mismatch for loops which has a single exit
to be deleted.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
Changes from v1:
* this is a simplification of what was trying to be done before.
gcc/ChangeLog:
PR tree-optimization/101256
* dbgcnt.def (phiopt_edge_range): New counter.
* tree-ssa
-tree-dump optimized
"__builtin_bswap|VEC_PERM_EXPR[^\n\r]*7, 6, 5, 4, 3, 2, 1, 0"
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-2036/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=ss
>>
> > >>
> > >> On 2021/6/25 16:54, Richard Biener wrote:
> > >>> On Fri, Jun 25, 2021 at 10:34 AM Xionghu Luo via Gcc-patches
> > >>> wrote:
> > >>>>
> > >>>> From: Xiong Hu Luo
> > &g
Hi,
This patch is to add test cases to check if vectorizer
can exploit vector multiply instrutions on Power, some
of them are supported since Power8, the other are newly
introduced by Power10.
Is it ok for trunk?
BR,
Kewen
-
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/mul
Hi,
This patch is to add one test case to check if vectorizer
can exploit vector division instrutions newly introduced
by Power10.
Is it ok for trunk?
BR,
Kewen
-
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/div-vectorize-1.c: New test.
---
.../gcc.target/powerpc/div-vectorize-1
Hi,
This patch is to make Power10 newly introduced vector
modulo instructions exploited in vectorized loops, it
just simply renames existing define_insns as standard
pattern names.
Is it ok for trunk?
BR,
Kewen
-
gcc/ChangeLog:
* config/rs6000/rs6000-builtin.def (MODS_V2DI
ng define_insns as standard
>> pattern names.
>
>>
>> Is it ok for trunk?
>>
>> BR,
>> Kewen
>> -
>> gcc/ChangeLog:
>>
>> * config/rs6000/rs6000-builtin.def (MODS_V2DI, MODS_V4SI, MODU_V2DI,
>> MODU_V4SI): Adjust
)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-2132/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux
Hi,
Ping.
— Jojo
在 2021年6月29日 +0800 PM4:11，Jojo R ，写道：
> T-HEAD extends some customized ISAs for Cores.
> The patches support ldr/str insns, it likes arm's LDR insn, the
> memory model is a base register indexed by (optionally scaled) register.
simplify and match for phiopt
[PHIOPT/MATCH] Remove the statement to move if not used
gcc/testsuite/gcc.dg/tree-ssa/pr96928-1.c | 5 +-
gcc/tree-ssa-phiopt.c | 86 +++
2 files changed, 76 insertions(+), 15 deletions(-)
--
2.27.0
From: Andrew Pinski
Instead of waiting for DCE to remove the unused statement,
and maybe optimize another conditional, it is better if
we don't move the statement and have the statement
removed.
gcc/ChangeLog:
* tree-ssa-phiopt.c (used_in_seq): New fun
to always passing
a pointer to the sequence and then decide based on if op is a
SSA_NAME or not.
OK? Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* tree-ssa-phiopt.c (phiopt_early_allow): Change arguments
to take sequence and gimple_match_op. Accept the case where
er of insertation and check to see if the lhs
is used rather than see if the lhs was used in the sequence.
gcc/ChangeLog:
* tree-ssa-phiopt.c (match_simplify_replacement): Move
insert of the sequence before the movement of the
statement. Check if to see if the statement is
Hi Richard,
on 2021/7/8 下午8:38, Richard Sandiford via Gcc-patches wrote:
> Quoting from the final patch in the series:
>
>
> This patch adds support for reusing a main loop's reduction accumulator
>
From: Andrew Pinski
This patch moves the (a-b) CMP 0 ? (a-b) : (b-a) optimization
from fold_cond_expr_with_comparison to match.
OK? Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* match.pd ((A-B) CMP 0 ? (A-B) : (B - A)):
New patterns.
gcc/testsuite/ChangeLog
Hi,
Ping.
@Jim @kito
— Jojo
在 2021年7月9日 +0800 AM9:30，ALO ，写道：
> Hi,
> Ping.
>
> — Jojo
> 在 2021年6月29日 +0800 PM4:11，Jojo R ，写道：
> > T-HEAD extends some customized ISAs for Cores.
> > The patches support ldr/str insns, it likes arm's LDR insn, the
> > memory model is a base r
On 2021-07-12 14:20, Richard Biener wrote:
On Fri, 9 Jul 2021, Segher Boessenkool wrote:
On Fri, Jul 09, 2021 at 08:43:59AM +0200, Richard Biener wrote:
> I wonder if there's a way to query the target what modes the doloop
> pattern can handle (not being too familiar with the doloop code).
You
On 2021-07-12 16:57, Richard Biener wrote:
On Mon, 12 Jul 2021, guojiufu wrote:
On 2021-07-12 14:20, Richard Biener wrote:
> On Fri, 9 Jul 2021, Segher Boessenkool wrote:
>
>> On Fri, Jul 09, 2021 at 08:43:59AM +0200, Richard Biener wrote:
>> > I wonder if there's a way to query the target what
On 2021-07-12 18:02, Richard Biener wrote:
On Mon, 12 Jul 2021, guojiufu wrote:
On 2021-07-12 16:57, Richard Biener wrote:
> On Mon, 12 Jul 2021, guojiufu wrote:
>
>> On 2021-07-12 14:20, Richard Biener wrote:
>> > On Fri, 9 Jul 2021, Segher Boessenkool wrote:
>> >
>> >> On Fri, Jul 09, 2021 at
On 2021-07-12 22:46, Richard Biener wrote:
On Mon, 12 Jul 2021, guojiufu wrote:
On 2021-07-12 18:02, Richard Biener wrote:
> On Mon, 12 Jul 2021, guojiufu wrote:
>
>> On 2021-07-12 16:57, Richard Biener wrote:
>> > On Mon, 12 Jul 2021, guojiufu wrote:
>> >
>> >> On 2021-07-12 14:20, Richard Bie
On 2021-07-12 23:53, guojiufu via Gcc-patches wrote:
On 2021-07-12 22:46, Richard Biener wrote:
On Mon, 12 Jul 2021, guojiufu wrote:
On 2021-07-12 18:02, Richard Biener wrote:
> On Mon, 12 Jul 2021, guojiufu wrote:
>
>> On 2021-07-12 16:57, Richard Biener wrote:
>> >
scan-tree-dump-times slp2
"optimized: basic block part" 1
FAIL: g++.dg/vect/slp-pr87105.cc -std=c++17 scan-tree-dump-times slp2
"optimized: basic block part" 1
FAIL: g++.dg/vect/slp-pr87105.cc -std=c++2a scan-tree-dump-times slp2
"optimized: basic block part&quo
On 2021-07-12 23:53, guojiufu via Gcc-patches wrote:
On 2021-07-12 22:46, Richard Biener wrote:
On Mon, 12 Jul 2021, guojiufu wrote:
On 2021-07-12 18:02, Richard Biener wrote:
> On Mon, 12 Jul 2021, guojiufu wrote:
>
>> On 2021-07-12 16:57, Richard Biener wrote:
>> >
On 2021-07-13 15:09, Richard Biener wrote:
On Tue, 13 Jul 2021, guojiufu wrote:
On 2021-07-12 23:53, guojiufu via Gcc-patches wrote:
> On 2021-07-12 22:46, Richard Biener wrote:
>> On Mon, 12 Jul 2021, guojiufu wrote:
>>
>>> On 2021-07-12 18:02, Richard Biener wrote:
&
d aarch64-linux-gnu.
BR,
Kewen
-
gcc/ChangeLog:
* tree-vect-patterns.c (vect_recog_mulhs_pattern): Add support to
recog normal multiply highpart.
---
gcc/tree-vect-patterns.c | 67
1 file changed, 48 insertions(+), 19 deletions(-)
diff --
P10 supported
binutils, will test more if the vectorizer patch gets
landed.
BR,
Kewen.
-
gcc/ChangeLog:
* config/rs6000/vsx.md (mulhs_): Rename to...
(smul3_highpart): ... this.
(mulhu_): Rename to...
(umul3_highpart): ... this.
* config/rs6000/rs6000
us]mul_highpart instead, much like the existing
> ones for MULH{R,}S?
>
OK, I was thinking the IFN way at the beginning, but was worried
that it's easy to be blamed saying it's not necessary since there
is one existing tree_code. :-) Will update it with IFN way.
BR,
Kewen
> R
on 2021/7/13 下午8:42, Richard Biener wrote:
> On Tue, Jul 13, 2021 at 12:25 PM Kewen.Lin wrote:
>>
>> Hi Richi,
>>
>> Thanks for the comments!
>>
>> on 2021/7/13 下午5:35, Richard Biener wrote:
>>> On Tue, Jul 13, 2021 at 10:53 AM Kewen.Lin wrote:
Hi,
When I added the support for
pr87105.cc -std=c++14 scan-tree-dump-times slp2 "basic
block part vectorized" 1
FAIL: g++.dg/vect/slp-pr87105.cc -std=c++17 scan-tree-dump-times slp2 "basic
block part vectorized" 1
FAIL: g++.dg/vect/slp-pr87105.cc -std=c++2a scan-tree-dump-times slp2 "basic
on 2021/7/14 上午6:07, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Jul 13, 2021 at 04:58:42PM +0800, Kewen.Lin wrote:
>> This patch is to make Power10 newly introduced vector
>> multiply high (part) instructions exploited in vectorized
>> loops, it renames existing define_insns as standard pattern
>
memory.o
textdata bss dec hex filename
115 0 0 115 73 memory.o
Bootstrapped and regtested on x86_64-linux-gnu{-m32,}
gcc/ChangeLog:
* config/i386/i386-expand.c
(ix86_broadcast_from_integer_constant): Rename to
ay.
At -O1, the loop is there.
.cfi_startproc
addi %r3,%r3,1
.L2:
addi %r9,%r3,-1
mr %r3,%r9
andi. %r9,%r9,0xff
bne %cr0,.L2
The patch v2
(https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574596.html)
could help it to be:
.cfi_startproc
On 2021-07-13 23:38, Segher Boessenkool wrote:
On Mon, Jul 12, 2021 at 08:20:14AM +0200, Richard Biener wrote:
On Fri, 9 Jul 2021, Segher Boessenkool wrote:
> Almost all targets just use Pmode, but there is no such guarantee I
> think, and esp. some targets that do not have machine insns for thi
On 2021-07-14 04:50, Segher Boessenkool wrote:
Hi!
On Tue, Jul 13, 2021 at 08:50:46PM +0800, Jiufu Guo wrote:
* doc/tm.texi: Regenerated.
Pet peeve: "Regenerate.", no "d".
Ok, yeap. While, 'Regenerate and Regenerated' were used by commits
somewhere :)
+DEFHOOK
+(preferred_dolo
295;
>> if (_76 <= 2)
>> goto ; [10.00%]
>> else
>> goto ; [90.00%]
>>
>>[local count: 167928121]:
>> _85 = (sizetype) _44;
>> _86 = _85 * 2;
>> vectp_small_a.23_84 = &small_a + _86;
>> vectp_small_b.26_9
Hi,
I ran into a wrong code bug in code with deep template instantiation when
working on sdx::simd.
The root cause as described in commit summary is we skip prologue insns in
init_alias_analysis.
This simple patch fixes the issue, however, it's hard to reduce a case because
of heavy use of
templ
Hi,
Like previous patch, this is found when I was playing with stx::simd. It's an
obvious
change as described in commit summary. Also the dead store in the code should
be
optimized away, but I guess there is no guarantee, so here is a simple patch
fixing it.
Is it OK?
Thanks,
bin
0002-AArc
Hi Richard,
on 2021/7/14 下午4:38, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> gcc/ChangeLog:
>>
>> * internal-fn.c (first_commutative_argument): Add info for IFN_MULH.
>> * internal-fn.def (IFN_MULH): New internal function.
>> * tre
On 2021-07-14 12:40, guojiufu via Gcc-patches wrote:
Updated the patch as below:
Thanks for comments.
gcc/ChangeLog:
2021-07-13 Jiufu Guo
PR target/61837
* config/rs6000/rs6000.c (TARGET_PREFERRED_DOLOOP_MODE): New hook.
(rs6000_preferred_doloop_mode): New hook
ses.
Like adjust_cond_for_loop_until_wrap, this patch enhance
function number_of_iterations_cond/number_of_iterations_lt
to analyze number of iterations for this kind of loop.
Bootstrap and regtest pass on powerpc64le, x86_64 and aarch64.
Is this ok for trunk?
gcc/ChangeLog:
2021-07-07 Jiufu
on 2021/7/14 下午7:32, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> on 2021/7/14 下午4:38, Richard Sandiford wrote:
>>> "Kewen.Lin" writes:
>>>> gcc/ChangeLog:
>>>>
>>>>* internal-fn.c (f
on 2021/7/15 上午3:32, Segher Boessenkool wrote:
> On Wed, Jul 14, 2021 at 12:32:24PM +0100, Richard Sandiford wrote:
>> TBH, 79 vs. 80 isn't normally something I'd worry about when reviewing
>> new code. But I know in the past people have asked for 79 to be used
>> for the “end+1” reason, so I don'
External declarations in ./gcc/toplev.h is no longer used in newest
version of gcc and should be cleaned up to avoid misunderstandings.
gcc/ChangeLog:
* toplev.h (set_random_seed):
---
diff --git a/gcc/toplev.h b/gcc/toplev.h
index 175944c..f543554 100644
--- a/gcc/toplev.h
+++ b/gcc
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571258.html
BR,
Kewen
on 2021/6/28 下午3:01, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> Gentle ping this:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571258.html
>
> BR,
> Kewen
-9.c -flto -ffat-lto-objects execution test
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-2300/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --w
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572555.html
BR,
Kewen
on 2021/6/28 下午3:00, Kewen.Lin via Gcc-patches wrote:
> Hi!
>
> I'd like to gentle ping this:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572555.html
>
>
&g
On 2021-07-15 02:04, Segher Boessenkool wrote:
Hi!
On Wed, Jul 14, 2021 at 06:26:28PM +0800, guojiufu wrote:
PR target/61837
Wrong PR number?
There is a patch optimize "add -1; zero_ext; add +1" to "zero_ext"
already.
Having this patch would help to avoid the left 'zero_ext', so, I
on 2021/7/14 下午3:45, Kewen.Lin via Gcc-patches wrote:
> on 2021/7/14 下午2:38, Richard Biener wrote:
>> On Tue, Jul 13, 2021 at 4:59 PM Kewen.Lin wrote:
>>>
>>> on 2021/7/13 下午8:42, Richard Biener wrote:
>>>> On Tue, Jul 13, 2021 at 12:25 PM Kewen.Lin wrote
Hi Uros,
on 2021/7/15 下午3:17, Uros Bizjak wrote:
> On Thu, Jul 15, 2021 at 9:07 AM Kewen.Lin wrote:
>>
>> on 2021/7/14 下午3:45, Kewen.Lin via Gcc-patches wrote:
>>> on 2021/7/14 下午2:38, Richard Biener wrote:
>>>> On Tue, Jul 13, 2021 at 4:59 PM Kewen.Lin wr
doloop iv.
And update doloop iv mode accordingly.
Bootstrap and regtest pass on powerpc64le, is this ok for trunk?
BR.
Jiufu
gcc/ChangeLog:
2021-07-13 Jiufu Guo
PR target/61837
* config/rs6000/rs6000.c (TARGET_PREFERRED_DOLOOP_MODE): New hook.
(rs6000_preferred_doloop_mode
on 2021/7/15 下午4:04, Kewen.Lin via Gcc-patches wrote:
> Hi Uros,
>
> on 2021/7/15 下午3:17, Uros Bizjak wrote:
>> On Thu, Jul 15, 2021 at 9:07 AM Kewen.Lin wrote:
>>>
>>> on 2021/7/14 下午3:45, Kewen.Lin via Gcc-patches wrote:
>>>> on 2021/7/14 下午2:3
on 2021/7/15 下午4:23, Uros Bizjak wrote:
> On Thu, Jul 15, 2021 at 10:04 AM Kewen.Lin wrote:
>>
>> Hi Uros,
>>
>> on 2021/7/15 下午3:17, Uros Bizjak wrote:
>>> On Thu, Jul 15, 2021 at 9:07 AM Kewen.Lin wrote:
>>>>
>>>> on 2021/7/14 下午3:45
ize of the buffer, I decided to
calculate the size at compile time and use constexpr to get a
constant for the size.
Since GCC is written in C++11, using constexpr is the best way
to force the size calculated at compile time.
OK? Bootstrapped and tested on x86_64-linux with no regressions.
gc
on 2021/7/15 下午7:58, Richard Biener wrote:
> On Thu, Jul 15, 2021 at 10:41 AM Kewen.Lin wrote:
>>
>> on 2021/7/15 下午4:04, Kewen.Lin via Gcc-patches wrote:
>>> Hi Uros,
>>>
>>> on 2021/7/15 下午3:17, Uros Bizjak wrote:
>>>> On Thu, Jul 15, 2021 a
ux with no regressions.
gcc/c-family/ChangeLog:
PR c/101453
* c-common.c (parse_optimize_options): Use the correct
size for buffer.
---
gcc/c-family/c-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
ind
From: Andrew Pinski
So the problem is even though there was a csneg with
a zero_extend in the front, there was not one for csinv.
This fixes it by extending that pattern.
OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions.
gcc/ChangeLog:
PR target/101205
From: Andrew Pinski
So the problem is even though there was a csneg with
a zero_extend in the front, there was not one for csinv.
This fixes it by extending that pattern.
OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions.
gcc/ChangeLog:
PR target/101205
ap-O3 config.
Any comments are appreciated.
BR,
Kewen
[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573424.html
[2] https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572315.html
-----
gcc/ChangeLog:
* cfgloop.h (class loop_iterator): Rename to ...
(class loops_list): ...
place the FOR_EACH_
>> loops with C++ 11 range loops, analogously to:
>> https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572315.html
>>
>> Finally, the only loosely followed naming convention for member
>> variables is to start them with the m_ prefix.
>>
>&g
as many calls to functions
>>>> like XNEW()/XNEWVEC() and free() use auto_vec instead).
>>>>
>>>> An unrelated but worthwhile change is to replace the FOR_EACH_
>>>> loops with C++ 11 range loops, analogously to:
>>>> https://gcc.gnu.org/piperma
On Wed, Jul 7, 2021 at 5:39 AM Martin Sebor via Gcc-patches
wrote:
>
> The recent patch series to improve warning suppression for inlined
> functions [PR98512] also implicitly includes the inlining context
> in all warning messages for inlined code. In r12-2091 I have
> committ
on 2021/7/19 下午2:26, Andrew Pinski wrote:
> On Sun, Jul 18, 2021 at 11:21 PM Kewen.Lin via Gcc-patches
> wrote:
>>
>> Hi,
>>
>> This patch follows Martin's suggestion here[1], to support
>> range-based for loops for traversing loops, analogously to
>&g
on 2021/7/19 下午10:08, Jonathan Wakely wrote:
> On Mon, 19 Jul 2021 at 07:20, Kewen.Lin wrote:
>>
>> Hi,
>>
>> This patch follows Martin's suggestion here[1], to support
>> range-based for loops for traversing loops, analogously to
>> the patch for vec[2].
>>
>> Bootstrapped and regtested on powerp
on 2021/7/19 下午10:34, Richard Biener wrote:
> On Mon, Jul 19, 2021 at 8:20 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> This patch follows Martin's suggestion here[1], to support
>> range-based for loops for traversing loops, analogously to
>> the patch for vec[2].
>>
>> Bootstrapped and regtested on power
on 2021/7/19 下午11:59, Martin Sebor wrote:
> On 7/19/21 12:20 AM, Kewen.Lin wrote:
>> Hi,
>>
>> This patch follows Martin's suggestion here[1], to support
>> range-based for loops for traversing loops, analogously to
>> the patch for vec[2].
>>
>> Bootstrapped and regtested on powerpc64le-linux-gnu
Hi:
As mention in https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575420.html
cut start-
> note for the lowpart we can just view-convert away the excess bits,
> fully re-using the mask. We generate surprisingly "good" code:
>
> kmovb %k1, %edi
>
linux-gnu P9,
x86_64-redhat-linux and aarch64-linux-gnu, also
bootstrapped again on ppc64le P9 with bootstrap-O3 config.
Does it look better? Is it ok for trunk?
BR,
Kewen
-
gcc/ChangeLog:
* cfgloop.h (as_const): New function.
(class loop_iterator): Rename to ...
to make the code look like:
>>
>> const auto& const_loops = loops_list (...);
>> for (const class loop *loop: const_loops)
>>
>> or
>> template constexpr const T &as_const(T &t) noexcept { return
>> t; }
>> for (const class loop
From: Andrew Pinski
The problem here is we try to an initialized value
from a scalar constant. For vectors we need to do
a vect_dup instead. This fixes that issue and we
get the correct code even and it does not crash.
OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions.
gcc
to
inconsistent behavior between soft-fp and avx512fp16 instructions, using option
-fexcess-precision=standard will force round back after every operation.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574112.html
There's 10 patches in this series:
1) Update hf soft-fp from gli
libgcc/ChangeLog
* soft-fp/eqhf2.c: New file.
* soft-fp/extendhfdf2.c: New file.
* soft-fp/extendhfsf2.c: New file.
* soft-fp/extendhfxf2.c: New file.
* soft-fp/half.h (FP_CMP_EQ_H): New marco.
* soft-fp/truncdfhf2.c: New file
* soft-fp/trunc
gcc/ChangeLog:
* config/i386/i386-modes.def (FLOAT_MODE): Define ieee HFmode.
* config/i386/i386.c (enum x86_64_reg_class): Add
X86_64_SSEHF_CLASS.
(merge_classes): Handle X86_64_SSEHF_CLASS.
(examine_argument): Ditto.
(construct_container): Ditto
gcc/ChangeLog:
* optabs-query.c (get_best_extraction_insn): Use word_mode for
HF field.
libgcc/ChangeLog:
* config/i386/32/sfp-machine.h (_FP_NANFRAC_H): New macro.
* config/i386/64/sfp-machine.h (_FP_NANFRAC_H): Ditto.
* config/i386/sfp-machine.h
From: "Guo, Xuepeng"
gcc/ChangeLog:
* common/config/i386/cpuinfo.h (get_available_features):
Detect FEATURE_AVX512FP16.
* common/config/i386/i386-common.c
(OPTION_MASK_ISA_AVX512FP16_SET,
OPTION_MASK_ISA_AVX512
gcc/ChangeLog:
* config/i386/avx512fp16intrin.h (_mm_set_ph): New intrinsic.
(_mm256_set_ph): Likewise.
(_mm512_set_ph): Likewise.
(_mm_setr_ph): Likewise.
(_mm256_setr_ph): Likewise.
(_mm512_setr_ph): Likewise.
(_mm_set1_ph): Likewise
gcc/testsuite/ChangeLog:
* gcc.target/i386/m512-check.h: Add union128h, union256h, union512h.
* gcc.target/i386/avx512fp16-10a.c: New test.
* gcc.target/i386/avx512fp16-10b.c: Ditto.
* gcc.target/i386/avx512fp16-1a.c: Ditto.
* gcc.target/i386/avx512fp16
From: "H.J. Lu"
gcc/testsuite/ChangeLog:
* gcc.target/i386/avx512fp16-vararg-1.c: New test.
* gcc.target/i386/avx512fp16-vararg-2.c: Ditto.
* gcc.target/i386/avx512fp16-vararg-3.c: Ditto.
* gcc.target/i386/avx512fp16-vararg-4.c: Ditto.
---
.../gcc.t
gcc/testsuite/ChangeLog:
* gcc.target/x86_64/abi/avx512fp16/m256h/abi-avx512fp16-ymm.exp:
New exp file.
* gcc.target/x86_64/abi/avx512fp16/m256h/args.h: New header.
* gcc.target/x86_64/abi/avx512fp16/m256h/avx512fp16-ymm-check.h:
Likewise
gcc/testsuite/ChangeLog:
* gcc.target/x86_64/abi/avx512fp16/m512h/abi-avx512fp16-zmm.exp:
New file.
* gcc.target/x86_64/abi/avx512fp16/m512h/args.h: Likewise.
* gcc.target/x86_64/abi/avx512fp16/m512h/asm-support.S: Likewise.
* gcc.target/x86_64/abi
: Use build_{one,zero}_cst and get the correct type before.
OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions.
gcc/ChangeLog:
PR tree-optimize/10153
* tree-tailcall.c (create_tailcall_accumulator):
Don't call fold_convert as the type should be co
Gentle ping. Any suggestions would be appreciated.
Thanks,
bin
On Wed, Jul 14, 2021 at 5:15 PM bin.cheng via Gcc-patches
wrote:
>
> Hi,
> I ran into a wrong code bug in code with deep template instantiation when
> working on sdx::simd.
> The root cause as described in commi
On 2021-06-21 20:36, Richard Biener wrote:
On Mon, 21 Jun 2021, guojiufu wrote:
On 2021-06-21 14:19, guojiufu via Gcc-patches wrote:
> On 2021-06-09 19:18, guojiufu wrote:
>> On 2021-06-09 17:42, guojiufu via Gcc-patches wrote:
>>> On 2021-06-08 18:13, Richard Biener wrote:
On Fri, Jul 23, 2021 at 7:53 AM Segher Boessenkool
wrote:
>
> On Wed, Jul 14, 2021 at 05:14:16PM +0800, bin.cheng via Gcc-patches wrote:
> > Hi,
> > I ran into a wrong code bug in code with deep template instantiation when
> > working on sdx::simd.
> > The roo
edhat-linux and aarch64-linux-gnu, also
bootstrapped again on ppc64le P9 with bootstrap-O3 config.
Is it ok for trunk?
BR,
Kewen
-----
gcc/ChangeLog:
* cfgloop.h (as_const): New function.
(class loop_iterator): Rename to ...
(class loops_list): ... this.
(loop_ite
r readability and
maintainability.
Bootstrapped and regtested on powerpc64le-linux-gnu P9,
x86_64-redhat-linux and aarch64-linux-gnu, also
bootstrapped on ppc64le P9 with bootstrap-O3 config.
Does the attached patch meet what you expect?
BR,
Kewen
-
gcc/ChangeLog:
* cfgloop.h (
ed_bss and x86_output_aligned_bss.
OK? Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
PR target/56337
* config/i386/i386-protos.h (x86_output_aligned_bss):
Change align argument to unsigned type.
(x86_elf_aligned_decl_common): Likewise.
* confi
On Sat, Jul 24, 2021 at 12:30 AM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 7/14/2021 3:14 AM, bin.cheng via Gcc-patches wrote:
> > Hi,
> > I ran into a wrong code bug in code with deep template instantiation when
> > working on sdx::simd.
> > The root cause
rict
> multiple_of_p queries to power-of-two bottoms, handle
> the all constant case inline.
>
> * gcc.dg/torture/pr100499-1.c: New testcase.
> * gcc.dg/torture/pr100499-2.c: Likewise.
> ---
> gcc/testsuite/gcc.dg/torture/pr1004
: gfortran.dg/PR93963.f90 -O2 execution test
FAIL: gfortran.dg/PR93963.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/PR93963.f90 -O3 -g execution test
FAIL: gfortran.dg/PR93963.f90 -Os execution test
with GCC configured
o read but more concise. Thanks again.
> I spotted what looks to me like a few minor typos in the docs
> diff:
>
> diff --git a/gcc/doc/loop.texi b/gcc/doc/loop.texi
> index a135656ed01..27697b08728 100644
> --- a/gcc/doc/loop.texi
> +++ b/gcc/doc/loop.texi
> @@ -79,14 +79
gt; that could result in inlining of a lot of these calls and so quite
> a bit code bloat. Unless this is necessary for efficiency (not
> my area) I would recommend to consider defining the loops_list
> ctor out-of-line in some .c or .cc file.
>
Yeah, they touch the same functions. Good
target_precision
for the scale_term matching check.
Bootstrapped & regtested on powerpc64le-linux-gnu P10,
powerpc64-linux-gnu P8, x86_64-redhat-linux and aarch64-linux-gnu.
Is it ok for trunk?
BR,
Kewen
-----
gcc/ChangeLog:
PR tree-optimization/100696
* tree-vect-patter
On Mon, Jul 26, 2021 at 11:07 PM Jeff Law wrote:
>
>
>
> On 7/25/2021 7:47 PM, Bin.Cheng wrote:
> > On Sat, Jul 24, 2021 at 12:30 AM Jeff Law via Gcc-patches
> > wrote:
> >>
> >>
> >> On 7/14/2021 3:14 AM, bin.cheng via Gcc-patches wrote:
>
for excess errors)
FAIL: g++.dg/pr71389.C (test for excess errors)
FAIL: g++.dg/pr71655.C (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-2533/usr
--enable-clocale=gnu --with-system-zlib --with
1801 - 1900 of 42321 matches
Mail list logo
