https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
Jan Hubicka changed:
What|Removed |Added
Summary|[13/14 Regression] |[13 regression] 456.hmmer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110857
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110857
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110727
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94427
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94427
--- Comment #4 from Jan Hubicka ---
It is the same loop - it was float only in my mind (since the function return
float value :)
With loop splitting we no longer have the last iteration check, but we still
have the underflow checks that are inde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110963
--- Comment #7 from Jan Hubicka ---
We don't consider main cold, but executed once: code out of loops is optimized
for size, but anything in loops is optimized according to -O setting. I did
not really think of users overwriting it by hot attri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110972
Bug ID: 110972
Summary: 13% fatigue regression between g:bb3ceeb6520c13fc
(2023-08-07 21:09) and g:d9dc70cc65becca9 (2023-08-08
13:30)
Product: gcc
Version: 13.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110972
--- Comment #1 from Jan Hubicka ---
The following patches in the range looks like they may cause the difference
commit d9f3ea61fe36e2de3354b90b65ff8245099114c9
Author: Richard Biener
Date: Mon Aug 7 14:44:20 2023 +0200
tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110973
Bug ID: 110973
Summary: 9% namd regression between g:c2a447d840476dbd
(2023-08-03 18:47) and g:73da34a538ddc2ad (2023-08-09
20:17)
Product: gcc
Version: 13.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110975
Bug ID: 110975
Summary: Missed unlooping
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
Jan Hubicka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110975
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110971
--- Comment #1 from Jan Hubicka ---
The problem here is that the split conditional is predicted with probability 0:
if (b.0_1 > a.4_14)
goto ; [0.00%]
else
goto ; [100.00%]
this is caused by jump threading;
[local count: 118111
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110988
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 110988, which changed state.
Bug 110988 Summary: [14 regression] ICE when building 523.xalancbmk_r with pgo
and lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110988
What|Removed |Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110971
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110940
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110923
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111064
Bug ID: 111064
Summary: 5-10% regression of parest on icelake between
g:d073e2d75d9ed492de9a8dc6970e5b69fae20e5a (Aug 15
2023) and g:9ade70bb86c8744f4416a48bb69cf4705f00905a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111064
--- Comment #1 from Jan Hubicka ---
Maybe
commit 3064d1f5c48cb6ce1b4133570dd08ecca8abb52d
Author: liuhongt
Date: Thu Aug 10 11:41:39 2023 +0800
Software mitigation: Disable gather generation in vectorization for GDS
affected Intel Proces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111054
--- Comment #2 from Jan Hubicka ---
This is a missing check for profile presence (we can not convert undefined
probability to sreal). I will fix that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
--- Comment #4 from Jan Hubicka ---
So here ipa-modref declares the field dead, while ipa-prop determines its value
even if it is unused and makes it used later?
I think dead argument is probably better than optimizing out one store, so I
think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110973
--- Comment #5 from Jan Hubicka ---
Note that some (not all?) namd scores seems to be back to pre-regression
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=798.120.0
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=791.120.0
ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111498
Bug ID: 111498
Summary: 951% profile quality regression between
g:93996cfb308ffc63 (2023-09-18 03:40) and
g:95d2ce05fb32e663 (2023-09-19 03:22)
Product: gcc
Vers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111551
Bug ID: 111551
Summary: Fix for PR106081 is not working with profile feedback
on imagemagick
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111552
Bug ID: 111552
Summary: 549.fotonik3d_r regression with -O2 -flto
-march=native on zen between g:85d613da341b7630
(2022-06-21 15:51) and g:ecd11acacd6be57a (2022-07-01
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111573
Bug ID: 111573
Summary: lambda functions often not inlined and optimized out
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59948
--- Comment #8 from Jan Hubicka ---
Trunk optimized stuff return 0, but fails to optimize out functions which
becomes unused after indirect inlining.
With -fno-early-inlining we end up with:
int m ()
{
void * D.48296;
int __args#0;
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116140
Jan Hubicka changed:
What|Removed |Added
Last reconfirmed||2024-08-01
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116296
--- Comment #2 from Jan Hubicka ---
It is most likely some problem with computing bit offsets for the alias oracle.
I guess multiplying that number by sizeof (long) * 11 * 11 * 8 triggers
overflow.
Probably harmless for -fdisable-checking gener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116582
Bug ID: 116582
Summary: gather is a win in some cases on zen CPUs
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116582
--- Comment #2 from Jan Hubicka ---
it is mysterious. I was looking into why in some cases the gather is a win in
micro-benchmark and loss in real benchmark. Indeed distribution of indices
makes difference.
If I make indices random then the pe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116582
--- Comment #3 from Jan Hubicka ---
Just for completeness the codegen for parest sparse matrix multiply is:
0.31 │320: kmovb %k1,%k4
0.25 │ kmovb %k1,%k5
0.28 │ vmovdqu32 (%rcx,%rax,1),%zmm0
0.32 │
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109213
--- Comment #8 from Jan Hubicka ---
We have large-stack-frame-growth that is relative, so yes, increasing stack
size of caller makes gcc to think that it is heavy and making it event heavier
will not hurt that much.
We originally ran into stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109341
Jan Hubicka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
--- Comment #21 from Jan Hubicka ---
Zen 1-3 changes were intentional in the original tuning patch (it is also
briefly mentioned in the commit message). By allowing 256 bit AVX moves
instead of 64bit integer moves (or 128bit) we can move bigger
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109509
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108086
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109509
--- Comment #5 from Jan Hubicka ---
For a summary
- PR109491 does not seem to be about integration time. most time is RTL PRE.
- PR108086 has 10% spent in integration and seems to be operand scan issue
- PR99785 is hard to judge given that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79416
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
--- Comment #26 from Jan Hubicka ---
reverted the znver1-3 change on gcc-12 branch. We still may want to fix IRA to
avoid the problem on core_avx512 targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109595
Bug ID: 109595
Summary: Missed upper bound on number of iterations
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109605
Bug ID: 109605
Summary: -fno-tree-vectorize does not disable vectorizer
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109690
Bug ID: 109690
Summary: bad SLP vectorization on zen
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109690
--- Comment #7 from Jan Hubicka ---
Thanks a lot! There however still seems to be problem with vectorization
On zen4 i now get:
jh@ryzen4:~/gcc/build/gcc> ./xgcc -B ./ -O2 -march=native slp.c ; perf stat
./a.out
Performance counter stats fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
Bug ID: 109849
Summary: suboptimal code for vector walking loop
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Ever confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #23 from Jan Hubicka ---
The patch looks reasonable. We probably could hash the padding vectors at
summary generation time to reduce WPA overhead, but that can be done
incrementally next stage1.
I however wonder if we really guarant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291
--- Comment #8 from Jan Hubicka ---
I am not sure this ought to be P1:
- the compilation technically is finite, but not in reasonable time
- it is possible to adjust the testcas (do early inlining manually) and get
same infinite build on relea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #25 from Jan Hubicka ---
So we have comdat groups that diverges in t1.o and t2.o. In one object it has
alias in it while in other object it does not
Merging nodes for _ZN6vectorI12QualityValueEC2ERKS1_. Candidates:
_ZN6vectorI12Qua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #27 from Jan Hubicka ---
OK, but the problem is same. Having comdats with same key defining different
set of public symbols is IMO not a good situation for both non-LTO and LTO
builds.
Unless the additional alias is never used by val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #28 from Jan Hubicka ---
So the main problem is that in t2 we have
_ZN6vectorI12QualityValueEC1ERKS1_/7 (vector<_Tp>::vector(const vector<_Tp>&)
[with _Tp = QualityValue])
Type: function definition analyzed alias cpp_implicit_alia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596
--- Comment #19 from Jan Hubicka ---
I looked into the remaining exit/nonexit rename discussed here earlier before
the PR was closed. The following patch would restore the code to do the same
calls as before my patch
PR tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114774
Bug ID: 114774
Summary: Missed DSE in simple code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114774
Jan Hubicka changed:
What|Removed |Added
Summary|Missed DSE in simple code |Missed DSE in simple code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #8 from Jan Hubicka ---
Note that cold attribute is also quite strong since it turns optimize_size
codegen that is often a lot slower.
Reading the discussion again, I don't think we have a way to make inline
keyword ignored by inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787
--- Comment #13 from Jan Hubicka ---
-fdump-tree-all-all changing generated code is also bad. We probably should
avoid dumping loop bounds then they are not recorded. I added dumping of loop
bounds and this may be unexpected side effect. WIll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
Bug ID: 114821
Summary: _M_realloc_append should use memcpy instead of loop to
copy data when possible
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #2 from Jan Hubicka ---
What I am shooting for is to optimize it later in loop distribution. We can
recognize memcpy loop if we can figure out that source and destination memory
are different.
We can help here with restrict, but I w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114822
Bug ID: 114822
Summary: ldist should produce memcpy/memset/memmove histograms
based on loop information converted
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #6 from Jan Hubicka ---
Thanks. I though the relocate_a only cares about the fact if the pointed-to
type can be bitwise copied. It would be nice to early produce memcpy from
libstdc++ for std::pair, so the second patch makes sense t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #8 from Jan Hubicka ---
I had wrong noexcept specifier. This version works, but I still need to inline
relocate_object_a into the loop
diff --git a/libstdc++-v3/include/bits/stl_uninitialized.h
b/libstdc++-v3/include/bits/stl_unini
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #9 from Jan Hubicka ---
Your patch gives me error compiling testcase
jh@ryzen3:/tmp> ~/trunk-install/bin/g++ -O3 ~/t.C
In file included from /home/jh/trunk-install/include/c++/14.0.1/vector:65,
from /home/jh/t.C:1:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #13 from Jan Hubicka ---
Thanks a lot, looks great!
Do we still auto-detect memmove when the copy constructor turns out to be
memcpy equivalent after optimization?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787
--- Comment #18 from Jan Hubicka ---
predict.cc queries number of iterations using number_of_iterations_exit and
loop_niter_by_eval and finally using estimated_stmt_executions.
The first two queries are not updating the upper bounds datastructu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113236
--- Comment #3 from Jan Hubicka ---
Seems this perofmance difference is still there on zen4
https://www.phoronix.com/review/gcc14-clang18-amd-zen4/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113235
--- Comment #9 from Jan Hubicka ---
Phoronix still claims the difference
https://www.phoronix.com/review/gcc14-clang18-amd-zen4/2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114852
Bug ID: 114852
Summary: jpegxl 10.0.1 is faster with clang18 then with gcc14
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #14 from Jan Hubicka ---
So this is problem in ipa_value_range_from_jfunc?
It is Maritn's code, I hope he will know why types are wrong here.
Once can get type compatibility problem on mismatched declarations and LTO, but
it seems th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115036
Bug ID: 115036
Summary: division is not shortened based on value range
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115037
Bug ID: 115037
Summary: Unused std::vector is not optimized away.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115037
Jan Hubicka changed:
What|Removed |Added
CC||jason at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #19 from Jan Hubicka ---
Note that the testcase from PR115037 also shows that we are not able to
optimize out dead stores to the vector, which is another quite noticeable
problem.
void
test()
{
std::vector test;
test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
Jan Hubicka changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14 Regression] Wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115277
Bug ID: 115277
Summary: ICF needs to match loop bound estimates
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115277
Jan Hubicka changed:
What|Removed |Added
Summary|ICF needs to match loop |[13/14/15 regression] ICF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67051
--- Comment #2 from Jan Hubicka ---
I believe that there was some discussion on this in the past. I would be quite
happy to change the predicate to be more aggressive. Current code basically
duplicates what original fold-const.c did.
One proble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811
--- Comment #13 from Jan Hubicka ---
So I re-tested it with current mainline and clang 16/17
For mainline I get (megapixels per second, bigger is better):
13.39
13.38
13.42
clang 16:
20.06
20.06
1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110641
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Jan Hubicka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112618
Bug ID: 112618
Summary: internal compiler error: in expand_MASK_CALL, at
internal-fn.cc:4529
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110287
--- Comment #8 from Jan Hubicka ---
With return value range propagation
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637265.html
reduces --param max-inline-insns-auto needed for _M_realloc_insert to be
inlined on my testcase from 39 t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #21 from Jan Hubicka ---
Patch
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637265.html
gets us closer to inlining _M_realloc_insert at -O3 (3 insns away)
Patch
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/6369
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110287
--- Comment #9 from Jan Hubicka ---
This is _M_realloc insert at release_ssa time:
eleased 63 names, 165.79%, removed 63 holes
void std::vector::_M_realloc_insert (struct vector *
const this, struct iterator __position, const struct pair_t & __
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110287
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653
Bug ID: 112653
Summary: We should optimize memmove to memcpy using alias
oracle
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110377
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110287
Bug 110287 depends on bug 110377, which changed state.
Bug 110377 Summary: Early VRP and IPA-PROP should work out value ranges from
__builtin_unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110377
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
Bug 109849 depends on bug 110377, which changed state.
Bug 110377 Summary: Early VRP and IPA-PROP should work out value ranges from
__builtin_unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110377
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653
--- Comment #3 from Jan Hubicka ---
PR82898 testcases seems to be about type based alias analysis. However PTA
should be useable here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98925
--- Comment #3 from Jan Hubicka ---
Return value range propagation was added in
r:53ba8d669550d3a1f809048428b97ca607f95cf5
however it works on scalar return values only for now. Extending it to
aggregates is a logical next step and should not be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112657
--- Comment #8 from Jan Hubicka ---
The negative return value branch predictor is set to have 98% hitrate (measured
on SPEC2k17 some time ago). There is --param predictable-branch-outcome that
is also set to 2% so indeed we consider the branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653
--- Comment #7 from Jan Hubicka ---
Thanks for explanation. I think it is quite common pattern that new object is
construted and worked on and later returned, so I think we ought to handle this
correctly.
Another example just came up in
https:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112706
Bug ID: 112706
Summary: missed simplification in FRE
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811
--- Comment #15 from Jan Hubicka ---
With SRA improvements r:aae723d360ca26cd9fd0b039fb0a616bd0eae363 we finally get
good performance at -O2. Improvements to push_back implementation also helps a
bit.
Mainline with default flags (-O2):
Inpu
501 - 600 of 861 matches
Mail list logo
