https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106343
Bug ID: 106343
Summary: Addition with constants is not vectorized by SLP when
it includes zero
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106346
Bug ID: 106346
Summary: Potential regression on vectorization of left shift
with constants
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106346
--- Comment #2 from manolis.tsamis at vrull dot eu ---
I bisected the changes from GCC 10.3 onwards and the first commit that results
in the "worse" version of the generated code is
9fc9573f9a5e9432e53c7de93985cfbd267f0309:
[2/3] [vect] Add wide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109393
Bug ID: 109393
Summary: Very trivial address calculation does not fold
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109393
--- Comment #2 from manolis.tsamis at vrull dot eu ---
(In reply to Andrew Pinski from comment #1)
> Note sometimes -fwrapv will optimize things because it can assume that
> overflow is defined as wrapping and this is one case that is true. Yes i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109393
--- Comment #4 from manolis.tsamis at vrull dot eu ---
(In reply to Richard Biener from comment #3)
> It's probably a mismatch of GENERIC/GIMPLE folding. In this case it's
> pointer_int_sum prematurely distributing the multiplication:
>
> /* Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109393
--- Comment #6 from manolis.tsamis at vrull dot eu ---
(In reply to Richard Biener from comment #5)
> (In reply to manolis.tsamis from comment #4)
> > Given the original transform it should be valid to propagate the constant
> > addition through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
Bug ID: 114010
Summary: Unwanted effects of using SSA free lists.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
--- Comment #4 from Manolis Tsamis ---
Hi Andrew,
Thank for your insights on this. Let me reply to some of your points:
(In reply to Andrew Pinski from comment #1)
> >The most important case I have observed is that the vectorizer can fail or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
--- Comment #5 from Manolis Tsamis ---
Also, I further investigated the codegen difference in the second example (zip
+ umlal vs umull) and it looks to be some sort of RTL ordering + combine issue.
Specifically, when the we expand the RTL for t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
--- Comment #10 from Manolis Tsamis ---
(In reply to ptomsich from comment #9)
> (In reply to Manolis Tsamis from comment #0)
> > E.g. another loop, non canonicalized names:
> >
> > .L120:
> > ldr q30, [x0], 16
> > moviv29.2s,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114287
Bug ID: 114287
Summary: [13.2.1 Regression] 416.gamess in SPEC CPU 2006
miscompiled
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114326
Bug ID: 114326
Summary: Missed optimization for A || B when !B implies A.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102793
Manolis Tsamis changed:
What|Removed |Added
CC||manolis.tsamis at vrull dot eu
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102793
--- Comment #7 from Manolis Tsamis ---
Also submitted in the lists:
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/648856.html
I should note that I needed to modify the test uninit-pred-6_c.c and remove
this check:
if (l)
if (n > 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115258
Bug ID: 115258
Summary: [14 Regression][aarch64] Additional XORs generated
after
r14-6290-g9f0f7d802482a8958d6cdc72f1fe0c8549db2182
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
--- Comment #8 from Manolis Tsamis ---
Created attachment 58335
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58335&action=edit
Do not modify live_out registers
After looking again at the dumps from PR112415, which I believe is closely
r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98138
manolis.tsamis at vrull dot eu changed:
What|Removed |Added
CC||manolis.tsamis at vrull d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110308
--- Comment #7 from manolis.tsamis at vrull dot eu ---
Some context for the commit:
This change is originally part of an late rtl pass to optimize memory accesses.
There are a lot of cases (especially involving local arrays) that generate
redunt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110308
--- Comment #10 from manolis.tsamis at vrull dot eu ---
Created attachment 55369
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55369&action=edit
ICE-fix-proposal-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
manolis.tsamis at vrull dot eu changed:
What|Removed |Added
CC||manolis.tsamis at vrull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110313
--- Comment #9 from manolis.tsamis at vrull dot eu ---
Hi,
This commit is known to be an issue and I'm working on a fix, you can find more
details on this ticket https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110308.
Would it be easy for you to t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267
Bug ID: 111267
Summary: Codegen regression from i386 argument passing changes
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109393
--- Comment #7 from Manolis Tsamis ---
After some attempts to improve on this, my current solution is:
1) Do not change pointer_int_sum in c-common (otherwise codegen regressions
are observed)
2) Introduce a pattern that folds (unsigned type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113089
Manolis Tsamis changed:
What|Removed |Added
CC||manolis.tsamis at vrull dot eu
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113089
--- Comment #3 from Manolis Tsamis ---
Created attachment 56908
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56908&action=edit
Reduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113089
--- Comment #6 from Manolis Tsamis ---
(In reply to Alex Coplan from comment #5)
> Also ICEs without -fno-strict-aliasing FWIW, so just -g -O2 -funroll-loops
> seems to be enough.
On my local build it doesn't reproduce without -fno-strict-alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113089
--- Comment #8 from Manolis Tsamis ---
(In reply to Alex Coplan from comment #7)
> (In reply to Manolis Tsamis from comment #6)
> > (In reply to Alex Coplan from comment #5)
> > > Also ICEs without -fno-strict-aliasing FWIW, so just -g -O2 -funr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109393
--- Comment #9 from Manolis Tsamis ---
Created attachment 55856
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55856&action=edit
Address calculation pattern v1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #11 from Manolis Tsamis ---
Hi all,
I will also go ahead and try to reproduce that, although it may take me some
time due to my limited experience with HPPA. Once I manage to reproduce, most
f-m-o issues are straightforward to locat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #15 from Manolis Tsamis ---
(In reply to Sam James from comment #13)
> Created attachment 56527 [details]
> compile.c.323r.fold_mem_offsets.bad.xz
>
> Output from
> ```
> hppa2.0-unknown-linux-gnu-gcc -c -DNDEBUG -g -fwrapv -O3 -Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #44 from Manolis Tsamis ---
(In reply to John David Anglin from comment #39)
> In the f-m-o pass, the following three insns that set call clobbered
> registers r20-r22 are pulled from loop:
>
> (insn 186 183 190 29 (set (reg/f:SI 22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #45 from Manolis Tsamis ---
(In reply to Jeffrey A. Law from comment #41)
> I would agree. In fact,the whole point of the f-m-o pass is to bring those
> immediates into the memory reference. It'd be really useful to know why
> that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #46 from Manolis Tsamis ---
I have reproduced the segfault with f-m-o limited to only fold insn 272 from
compiler_call_helper. The exact transformation is:
Memory offset changed from 0 to 388 for instruction:
(insn 273 272 276 30 (s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #48 from Manolis Tsamis ---
(In reply to dave.anglin from comment #47)
> On 2023-11-13 4:33 a.m., manolis.tsamis at vrull dot eu wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
> >
> > --- Comment #44 from Manolis Tsam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #52 from Manolis Tsamis ---
(In reply to Sam James from comment #51)
> manolis, did you have a chance to look at the remaining pass issue? You'll
> need to revert Dave's commit locally which made the issue latent for
> building Pytho
36 matches
Mail list logo
