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=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=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=119209
Bug ID: 119209
Summary: SLP failed to recognize dot_prod pattern(it's taked as
a normal reduction)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119181
Bug ID: 119181
Summary: Missed vectorization due to imperfect SLP discovery
for strided & interleaved load.
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Seve
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.
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 #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 #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);
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=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=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=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=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=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=117452
Hongtao Liu changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
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 #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=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
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=119617
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
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=119596
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=119464
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=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=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 #12 from Hongtao Liu ---
Let's just fix it in GCC16, either solution is ugly.
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=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=119368
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108134
Hongtao Liu changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
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=119879
Bug ID: 119879
Summary: [r16-39 Regression] FAIL:
gcc.target/i386/avx512fp16-trunc-extendvnhf.c
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119879
Hongtao Liu changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|16.0
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=118508
Hongtao Liu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
501 - 544 of 544 matches
Mail list logo
