https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118581
Hongtao Liu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119879
Hongtao Liu changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|16.0
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: liuhongt at gcc dot gnu.org
Target Milestone: ---
[r16-39 Regression] FAIL: gcc.target/i386/avx512fp16-trunc-extendvnhf.c
On Linux/x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108134
Hongtao Liu changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108134
--- Comment #4 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #3)
> (In reply to sandra from comment #2)
> > This was introduced by commit 0fec3f62b9bfc03e5088a09036791c2ac84fe0c8. I
> > wondered if there might have been a patch hun
at gcc dot gnu.org |liuhongt at gcc dot
gnu.org
--- Comment #3 from Hongtao Liu ---
(In reply to sandra from comment #2)
> This was introduced by commit 0fec3f62b9bfc03e5088a09036791c2ac84fe0c8. I
> wondered if there might have been a patch hunk to update the example that
> didn&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119617
--- Comment #12 from Hongtao Liu ---
Let's just fix it in GCC16, either solution is ugly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118551
--- Comment #6 from Hongtao Liu ---
(In reply to Jan Hubicka from comment #5)
> as discussed in PR111551 the SPEC train run does not include hottest loop of
> MorphologyApply, so MeanShiftImage may have same issue and auto-fdo may be
> kind of c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119617
--- Comment #6 from Hongtao Liu ---
(In reply to Haochen Jiang from comment #4)
> (In reply to Hongtao Liu from comment #3)
> > (In reply to Hongtao Liu from comment #2)
> > > (In reply to Richard Biener from comment #1)
> > > > I think we need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119617
--- Comment #3 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #2)
> (In reply to Richard Biener from comment #1)
> > I think we need to disable the effect of -mno-evex512, looks like there's
> > still traces of it left?
>
> Let's ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119617
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102294
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119596
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101017
--- Comment #13 from Hongtao Liu ---
(In reply to David Binderman from comment #12)
> (In reply to Hongtao Liu from comment #11)
> > (In reply to David Binderman from comment #10)
> > > Did this ever happen ?
> > >
> > > Similar test case gcc/t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119464
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119368
--- Comment #4 from Hongtao Liu ---
>
> But for this case, I think targetm.can_change_mode_class (op_mode,
> result_mode, ALL_REGS) is not needed since it's memory.
I mean case in #c1, for case in #c0, it's more complicated.
1. It's also rela
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #18 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #16)
> >
> > 4952 /* See if a MEM has already been loaded with a widening operation;
> > 4953 if it has, we can use a subreg of that. Many CISC machines
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119368
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119425
Hongtao Liu changed:
What|Removed |Added
CC||lin1.hu at intel dot com
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117452
Hongtao Liu changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115842
--- Comment #8 from Hongtao Liu ---
(In reply to Tamar Christina from comment #7)
> (In reply to Hongtao Liu from comment #6)
> > I noticed some double-counting of cost in group-candidate (regarding loop
> > invariant expressions), this modific
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118753
Bug 118753 depends on bug 117069, which changed state.
Bug 117069 Summary: [15 Regression] gcc.target/i386/apx-ndd-tls-1b.c since
r15-268-g9dbff9c05520a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069
Hongtao Liu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
||liuhongt at gcc dot gnu.org
--- Comment #4 from Hongtao Liu ---
I'll take a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069
--- Comment #15 from Hongtao Liu ---
(In reply to Sam James from comment #7)
> This stopped failing for me around:
>
> commit 2bc3ea210565dc7cdbba9adb31acceefed406254
> Author: Sam James
> Date: Fri Nov 22 15:20:45 2024 +
>
> saving
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069
--- Comment #14 from Hongtao Liu ---
(In reply to Sam James from comment #13)
> (In reply to Hongtao Liu from comment #9)
> > I didn't find this commit in gcc trunk?
>
> Ah, sorry for confusion: it's from my local test results. Only the date
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069
--- Comment #9 from Hongtao Liu ---
(In reply to Sam James from comment #7)
> This stopped failing for me around:
>
> commit 2bc3ea210565dc7cdbba9adb31acceefed406254
> Author: Sam James
> Date: Fri Nov 22 15:20:45 2024 +
>
> saving
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069
--- Comment #8 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #6)
> It looks like the testcase is fragile, it's supposed to check the compiler
> ability of generating code_6_gottpoff_reloc instruction, but failed since
> there's a se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978
--- Comment #33 from Hongtao Liu ---
I have a fix in ivopt for x86 in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115842#c6, you may try to see if
that helps?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119181
--- Comment #11 from Hongtao Liu ---
More common case is
typedef int v8si __attribute__((vector_size(32)));
v8si
foo1 (v8si a, v8si b)
{
v8si c = __builtin_shufflevector (a, b, 0, 1, 2, 11, 4, 5, 6, 15);
v8si d = __builtin_shufflevect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119181
--- Comment #10 from Hongtao Liu ---
But it still can't fix the issue with
void
foo (int* a, int* restrict b)
{
b[0] = a[0] * a[8];
b[1] = a[1] * a[9];
b[2] = a[2] * a[10];
b[3] = a[11] * a[3];
b[4] = a[12] * a[4];
b[5]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119181
--- Comment #8 from Hongtao Liu ---
(In reply to Richard Biener from comment #7)
> The issue is we detect this as a single interleaving group:
>
> t.c:12:1: note: Detected interleaving load of size 264
> t.c:12:1: note: _1 = *a_26(D);
erity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: liuhongt at gcc dot gnu.org
Target Milestone: ---
int
foo (unsigned char* a, char* b, int n, int stride, int* __restrict dst)
{
int sum = 0;
sum +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119181
--- Comment #6 from Hongtao Liu ---
void
foo (int* a, int* __restrict b, int* c)
{
b[0] = a[0] * c[256];
b[1] = c[257] * a[1];
b[2] = a[2] * c[258];
b[3] = c[259] * a[3];
b[4] = c[260] * a[4];
b[5] = c[261] * a[5];
b[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119181
--- Comment #3 from Hongtao Liu ---
void
foo (int* a, int* __restrict b)
{
b[0] = a[0] * a[256];
b[1] = a[257] * a[1];
b[2] = a[2] * a[258];
b[3] = a[259] * a[3];
b[4] = a[260] * a[4];
b[5] = a[261] * a[5];
b[6] = a[6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119181
--- Comment #5 from Hongtao Liu ---
>
> Looks like if both operands satisfy same STMT_VINFO_GROUPED_ACCESS as first
> stmt, we'd better have a heuristic to choose more closer one?
If all grouped operations satisfy commutative property.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119181
--- Comment #2 from Hongtao Liu ---
(In reply to Andrew Pinski from comment #1)
> Looks like it is missing the commutativity property of multiply.
Note compiler options is with Ofast.
RMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: liuhongt at gcc dot gnu.org
Target Milestone: ---
void
foo (double* a, double* __restrict b)
{
b[0] = a[0] * a[256];
b[1] = a[257] * a[1];
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119142
--- Comment #6 from Hongtao Liu ---
(In reply to Haochen Jiang from comment #5)
> (In reply to Haochen Jiang from comment #4)
> > I suppose that patch should be reverted, caused by Richard S's patch.
> >
> > https://gcc.gnu.org/pipermail/gcc-re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115842
--- Comment #6 from Hongtao Liu ---
I noticed some double-counting of cost in group-candidate (regarding loop
invariant expressions), this modification reduces the number of instructions
executed by ~8% for exchange_r binary compiled with -marc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119083
--- Comment #10 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #9)
> (In reply to H.J. Lu from comment #8)
> > Created attachment 60647 [details]
> > A patch to remove CREG and BREG from ix86_class_likely_spilled_p
> >
> > Hongtao,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119103
--- Comment #5 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #4)
> vect_recog_over_widening_pattern could be extended with range info for this?
Looks like vectorizer already have range_info from
vect_determine_precisions_from_range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119103
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119083
--- Comment #9 from Hongtao Liu ---
(In reply to H.J. Lu from comment #8)
> Created attachment 60647 [details]
> A patch to remove CREG and BREG from ix86_class_likely_spilled_p
>
> Hongtao, can you measure its impact on SPEC CPU 2017?
Ok.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118996
--- Comment #16 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #14)
> (In reply to H.J. Lu from comment #13)
> > (In reply to H.J. Lu from comment #11)
> > > Created attachment 60609 [details]
> > > An untested patch
> >
> > Hongtao
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119083
--- Comment #7 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #5)
> (In reply to H.J. Lu from comment #3)
> > Created attachment 60640 [details]
> > A patch to remove SSE_FIRST_REG from ix86_class_likely_spilled_p
> >
> > Hongtao, c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118996
--- Comment #14 from Hongtao Liu ---
(In reply to H.J. Lu from comment #13)
> (In reply to H.J. Lu from comment #11)
> > Created attachment 60609 [details]
> > An untested patch
>
> Hongtao, do you have SPEC CPU2017 data on this patch?
I haven
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119083
--- Comment #5 from Hongtao Liu ---
(In reply to H.J. Lu from comment #3)
> Created attachment 60640 [details]
> A patch to remove SSE_FIRST_REG from ix86_class_likely_spilled_p
>
> Hongtao, can you measure its impact on SPEC CPU2017?
Sure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118996
--- Comment #7 from Hongtao Liu ---
(In reply to H.J. Lu from comment #6)
> SMALL_REGISTER_CLASSES was added by
>
> commit c98f874233428d7e6ba83def7842fd703ac0ddf1
> Author: James Van Artsdalen
> Date: Sun Feb 9 13:28:48 1992 +
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992
--- Comment #13 from Hongtao Liu ---
(In reply to H.J. Lu from comment #11)
> Created attachment 60590 [details]
> A patch
>
> Can you try this on SPEC CPU?
No big impact for both O2 and Ofast on SPEC2017.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118994
--- Comment #7 from Hongtao Liu ---
diff --git a/gcc/match.pd b/gcc/match.pd
index 5c679848bdf..d6a465c963c 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -11348,3 +11348,28 @@ and,
}
(if (full_perm_p)
(vec_perm (op@3 @0 @
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069
--- Comment #6 from Hongtao Liu ---
It looks like the testcase is fragile, it's supposed to check the compiler
ability of generating code_6_gottpoff_reloc instruction, but failed since
there's a seg_prefixed memory usage(r14-6242-gd564198f960a2f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069
Hongtao Liu changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118753
Bug 118753 depends on bug 117069, which changed state.
Bug 117069 Summary: [15 Regression] gcc.target/i386/apx-ndd-tls-1b.c since
r15-268-g9dbff9c05520a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069
Hongtao Liu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992
--- Comment #12 from Hongtao Liu ---
(In reply to H.J. Lu from comment #11)
> Created attachment 60590 [details]
> A patch
>
> Can you try this on SPEC CPU?
Sure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118753
Bug 118753 depends on bug 117069, which changed state.
Bug 117069 Summary: [15 Regression] gcc.target/i386/apx-ndd-tls-1b.c since
r15-268-g9dbff9c05520a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118994
--- Comment #6 from Hongtao Liu ---
(In reply to John Platts from comment #5)
> GCC also fails to optimize (a | b) - ((a ^ b) >> 1) down to a single SSE2
> PAVGB/PAVGW, NEON/SVE2 SRHADD/URHADD, AltiVec
> vavgsb/vavgsh/vavgsw/vavgub/vavguh/vavguw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992
--- Comment #9 from Hongtao Liu ---
(In reply to H.J. Lu from comment #8)
> (In reply to Richard Biener from comment #7)
>
> >
> > >else if (targetm.small_register_classes_for_mode_p (GET_MODE (x)))
> > > record = false;
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118996
--- Comment #3 from Hongtao Liu ---
Original commit is added to avoid reload failure ~24 years ago, maybe we can
try to remove the check in cse.cc.
commit 8bf4dfc24f1957b8f645e362e354655fb851fc89
Author: Geoffrey Keating
Date: Mon Jul 2 23:2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118994
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118996
--- Comment #1 from Hongtao Liu ---
Looking at the hook description, it looks like x86 still need nozero return
values under apx (due to AREG, DREG, CREG, BREG, SIREG, DIREG)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118802
--- Comment #22 from Hongtao Liu ---
(In reply to Sam James from comment #16)
> Bisected to r15-7400-gd3ff498c478ace (not CCing anyone yet as not enough
> useful information).
There's a new patch in [1] which will revert the commit and may fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #11 from Hongtao Liu ---
(In reply to Miao Wang from comment #10)
> (In reply to Hongtao Liu from comment #9)
> > >
> > > > Because I think the operands usage is broken.
> > >
> > > Additionally, by removing the do{ ... } while(0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #9 from Hongtao Liu ---
>
> > Because I think the operands usage is broken.
>
> Additionally, by removing the do{ ... } while(0) wrap from
> bigint_test_exec(), the issue disappears. I believe that if it is the
> operands usage is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117081
--- Comment #20 from Hongtao Liu ---
>
> W/o more usage of callee-saved registers, callee needs to restore them
> before exit which is not needed if more caller-saved register are used.
W/ https://gcc.gnu.org/pipermail/gcc-patches/2025-Februa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117081
--- Comment #19 from Hongtao Liu ---
(In reply to H.J. Lu from comment #18)
> (In reply to Haochen Jiang from comment #17)
> >
> > For reproduce, not only on ADL, the fix patch showed regression on all
> > Cascade Lake/Ice Lake/Sapphire Rapids w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108707
--- Comment #11 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #10)
> (In reply to Pranav Gorantla from comment #9)
> > Facing similar issue in gcc-13. Is it possible to backport the fix of this
> > Bug 108707 and Bug 109610 to gcc-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118623
--- Comment #17 from Hongtao Liu ---
(In reply to Jakub Jelinek from comment #15)
> Created attachment 60411 [details]
> gcc15-pr118623.patch
>
> Untested patch which seems to work for me on the new testcases and
> i386.exp=bt*.c so far.
When
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118623
--- Comment #16 from Hongtao Liu ---
(In reply to Jakub Jelinek from comment #14)
> So, if (reg:CCC flags) being non-zero in RTL means nc and (reg:CCC flags)
> being zero in RTL means c, shouldn't *bt be using (compare:CCC
> (zero_extract ...) (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117081
--- Comment #16 from Hongtao Liu ---
(In reply to H.J. Lu from comment #15)
> r15-7400-gd3ff498c478ace gave
>
> $ cat x.c
> int f (int);
> int
> advance (int dz)
> {
> if (dz > 0)
> return (dz + dz) * dz;
> else
> return dz * f (dz)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117081
--- Comment #14 from Hongtao Liu ---
> can be sinked to else branch(as sub + mov). When jle .L2 is not taken,
> it can save one push instruction. And that's why 511.povray_r is improved.
plus one pop instruction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117081
--- Comment #13 from Hongtao Liu ---
(In reply to H.J. Lu from comment #10)
> (In reply to Hongtao Liu from comment #9)
> > (In reply to Hongtao Liu from comment #8)
> > > (In reply to H.J. Lu from comment #7)
> > > > Created attachment 60350 [d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108707
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117081
--- Comment #9 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #8)
> (In reply to H.J. Lu from comment #7)
> > Created attachment 60350 [details]
> > ira: Don't increase callee-saved register cost by 1000x
>
> NOTE, r15-1619-g3b9b8d6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117081
--- Comment #8 from Hongtao Liu ---
(In reply to H.J. Lu from comment #7)
> Created attachment 60350 [details]
> ira: Don't increase callee-saved register cost by 1000x
NOTE, r15-1619-g3b9b8d6cfdf593 improved 500.perlbench_r on many different
p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79786
--- Comment #11 from Hongtao Liu ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Hongtao Liu from comment #7)
> > (In reply to Richard Biener from comment #6)
> > > Hongtao - do we care about -miamcu? Should we eventually deprecat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117082
--- Comment #6 from Hongtao Liu ---
(In reply to H.J. Lu from comment #5)
> It isn't a dup of PR 117081 since it is a different failure.
But it's caused by the same commit and the same rootcause?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118623
--- Comment #12 from Hongtao Liu ---
1370Trying 35 -> 20:
1371 35: flags:CCC=cmp(zero_extract(r104:SI,0x1,r105:SI#0),0)
1372 REG_DEAD r104:SI
1373 REG_DEAD r105:SI
1374 20: pc={(flags:CCC!=0)?L26:pc}
1375 REG_BR_PROB 107374183
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118623
--- Comment #11 from Hongtao Liu ---
283(insn 8 7 9 2 (set (reg:SI 107)
284(const_int 1 [0x1])) "test.c":3:7 -1
285 (nil))
286(insn 9 8 10 2 (parallel [
287(set (reg:SI 106 [ e_7 ])
288(ashift:SI (reg:SI 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118623
--- Comment #10 from Hongtao Liu ---
> > r12-7751-g919fbffef07555
>
> that might have just exposed a latent issue
Should be, the guilty commit just extent a splitter to handle reversed
condition, didn't see anything abnormal.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118581
--- Comment #5 from Hongtao Liu ---
(In reply to Richard Biener from comment #2)
> (In reply to Richard Biener from comment #1)
> > Does it have counter info for PHI arguments (aka copies emitted on those
> > edges)?
>
> I think yes, so IMO it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118581
--- Comment #4 from Hongtao Liu ---
Note it's from SPEC2017 519.lbm_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118581
--- Comment #3 from Hongtao Liu ---
(In reply to Richard Biener from comment #2)
> (In reply to Richard Biener from comment #1)
> > Does it have counter info for PHI arguments (aka copies emitted on those
> > edges)?
>
> I think yes, so IMO it
IRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: liuhongt at gcc dot gnu.org
Target Milestone: ---
The source code is like
if( TEST_FLAG_SWEEP( srcGrid,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118551
--- Comment #3 from Hongtao Liu ---
(In reply to Andrew Pinski from comment #1)
> I think this is similar to pr 113646 really.
Looks like PR 113646 is PGO not autofdo, so the issue could be different.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118551
--- Comment #2 from Hongtao Liu ---
A hack like below can recove performance and further improved 538.imagick_r by
5% w/ autofdo.
The hack prevents the scaling if ipa_count is zero but function body is hot.
diff --git a/gcc/predict.cc b/gcc/pr
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: liuhongt at gcc dot gnu.org
Target Milestone: ---
Similar like PR116743, it's related to ipa scaling, but in different
place(estimate_bb_frequencies).
/* If we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118489
Hongtao Liu changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: liuhongt at gcc dot gnu.org
Target Milestone: ---
with -march=x86-64-v3 -O2.
part of dump_gcov is like
__step3d_t_mod_MOD_step3d_t total:5500129 head:0
0: 0
29: 0
30
|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |liuhongt at gcc dot
gnu.org
Ever confirmed|0 |1
|---
Assignee|liuhongt at gcc dot gnu.org|unassigned at gcc dot
gnu.org
Status|ASSIGNED|UNCONFIRMED
Ever confirmed|1 |0
--- Comment #2 from Hongtao Liu ---
There're typo in the commit, sorry for
at gcc dot gnu.org |liuhongt at gcc dot
gnu.org
Ever confirmed|0 |1
Last reconfirmed||2025-01-16
--- Comment #1 from Hongtao Liu ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118333
Hongtao Liu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863
Bug 89863 depends on bug 118333, which changed state.
Bug 118333 Summary: gcc/config/i386/i386-expand.cc:24871: Pointless condition ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118333
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115777
--- Comment #10 from Hongtao Liu ---
> That's probably the conservative answer for BB vectorization, for loop vect
> we know all those uses will be also in vector code. For BB vectorization
> there is currently no easly reliable check to ensur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115777
--- Comment #8 from Hongtao Liu ---
> in backend costing we do anticipate the vector construction to happen
> by loading from memory though, so we don't account for the extra
> GPR->xmm move penalty.
Yes, I saw something similar before and had
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118380
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118333
--- Comment #2 from Hongtao Liu ---
(In reply to Uroš Bizjak from comment #1)
> (In reply to David Binderman from comment #0)
> > Static analyser cppcheck says:
> >
> > gcc/config/i386/i386-expand.cc:24871:35: warning: Identical condition
> > '
issed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: liuhongt at gcc dot gnu.org
Blocks: 53947
Target Milestone: ---
double
foo (double* a, double* b, double c)
{
c +=
1 - 100 of 552 matches
Mail list logo
