https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119298
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 119298, which changed state.
Bug 119298 Summary: [15/16 Regression] 538.imagick_r is faster when compiled
with GCC 14.2 and -Ofast -flto -march=native than with master on Zen5 since
r15-3441-g4292297a0f938f
https://gcc.g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120218
--- Comment #2 from Jan Hubicka ---
I guess for costing changes, too. Since this is a weekly tester, bisecting
would help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120219
Jan Hubicka changed:
What|Removed |Added
Depends on||119902
--- Comment #5 from Jan Hubicka -
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
This is visible on both Zen and Intel testers
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=298.407.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120099
--- Comment #4 from Jan Hubicka ---
This patch enables more inlining, so I guess it is previously latent problem
triggered by inliner...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120120
--- Comment #9 from Jan Hubicka ---
Forgot to say, -fno-optimize-sibbling-calls re-enables the cloning & inline.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120120
--- Comment #8 from Jan Hubicka ---
The difference is that tailr1 pass now turns recursion into loop.
GCC15 does:
Basic block 11 has extra exit edges
Basic block 33 has extra exit edges
Basic block 28 has extra exit edges
Basic block 23 has ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120120
Jan Hubicka changed:
What|Removed |Added
Last reconfirmed||2025-05-06
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120069
Jan Hubicka changed:
What|Removed |Added
Last reconfirmed||2025-05-03
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119900
--- Comment #6 from Jan Hubicka ---
Sadly this did not fix the whole regression. The problem is that after my
change to enable ipa-cp to clone over cold edges we clone
GetVirtualPixelsFromNexus twice (as constprop.0 and constprop.1). This
func
:55b01e17c793688a2878fa43a76df1266153b438
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120065
--- Comment #3 from Jan Hubicka ---
while (n > 0 && a)
;
This is an odd loop which loops iterates 0 times or infinitely many times.
We do not pattern match that at profile-estimate time (since such code is kind
of useless) and we guess i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119900
Jan Hubicka changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119900
--- Comment #3 from Jan Hubicka ---
Reverting the change of size_costs solves the regression, so it is about
differences in optimization of cold code. I will try to track down what causes
that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119900
--- Comment #2 from Jan Hubicka ---
aha, I mistakely added analysis to PR105275. One problem I noticed was wrong
costing of FP scalar min/max which is fixed now but does not affect imgick.
Interesting is that we now vectorized same loops and BBs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103734
--- Comment #5 from Jan Hubicka ---
This is MorphologyApply
MagickExport Image *MorphologyApply(const Image *image, const ChannelType
channel,const MorphologyMethod method, const ssize_t iterations,
const KernelInfo *kernel, const Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103734
--- Comment #4 from Jan Hubicka ---
With -fprofile-use we get
Evaluating opportunities for MorphologyApply/3266.
- considering value 134217719 for param #1 const ChannelType (caller_count: 3)
good_cloning_opportunity_p (time: 1, size: 427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105275
--- Comment #9 from Jan Hubicka ---
The only vectorization difference is:
+imagick_r.ltrans8.ltrans.189t.slp1:magick/distort.c:1911:18: optimized: basic
block part vectorized using 16 byte vectors
+imagick_r.ltrans8.ltrans.189t.slp1:magick/dist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105275
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119924
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119919
--- Comment #6 from Jan Hubicka ---
Exchange2 regression is solved and tonto seem to be noise (performance is back
today w/o change of a checksum of the text segment).
still we account one extra setcc and misaccount scatter, so lets keep this t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119919
Jan Hubicka changed:
What|Removed |Added
Depends on||119902
--- Comment #3 from Jan Hubicka -
|ASSIGNED
Last reconfirmed||2025-04-24
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #2 from Jan Hubicka ---
This is with -O2 only. Difference is
+++ bbb 2025-04-24 16:21:25.029155295 +0200
@@ -108,10 +108,7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119147
--- Comment #5 from Jan Hubicka ---
as g:132d01d96ea9d617aaffdd5dfba3284a8958e529 I have committed the patch that
enables ipa-cp to clone over edges which are !maybe_hot_p().
This improves x264 with FDO by 7.8% and exchange by 3.3%
It causes qu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119919
--- Comment #1 from Jan Hubicka ---
There is also 4% tonto regression in Intel in the same range it seems
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=799.230.0
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
this reproduces both on Zen and Intel:
https
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
As discussed in
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681555.html
in loop
> void foo (int n, int *
: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
this seems to reproduce on Intel (119%)
https://lnt.opensuse.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119879
--- Comment #2 from Jan Hubicka ---
Created attachment 61166
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61166&action=edit
Fix I am testing
The fix I am testing. When VEC_PACK_TRUNC_EXPR is used, add_hook is called with
vec_promote_dem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119879
--- Comment #1 from Jan Hubicka ---
The problem is in:
/* VEC_PACK_TRUNC_EXPR: If inner size is greater than outer size we will end
up doing two conversions and packing them. */
if (!scalar_p && inner_size > outer_size)
{
i
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
int a[1000];
int b[1000];
int c[1000];
int d[1000];
void test()
{
for (int i = 0; i < 1000; i++)
a[i] = b[i] > 0 ? c[i] + 1 : c[i] + 2;
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
double a[1000];
double b[1000];
double c[1000];
double d[1000];
void test()
{
for (int i = 0; i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #47 from Jan Hubicka ---
Created attachment 61134
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61134&action=edit
patch w/o forgotten debug output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #46 from Jan Hubicka ---
Created attachment 61133
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61133&action=edit
updated patch
The problem in previous patch was that ipa-prop streams 0 to the end of block
of summary section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #44 from Jan Hubicka ---
Summaries are duplicated when clone is created. Let me debug why it gets lost
here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #37 from Jan Hubicka ---
Created attachment 61128
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61128&action=edit
updated patch (regtests and bootstraps)
Updated patch. Streaming summaries seems to work and fixes the testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #36 from Jan Hubicka ---
Created attachment 61127
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61127&action=edit
patch (untested)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #34 from Jan Hubicka ---
I there is only problem that ipa_return_value_sum value sum does not survive
from compile time to WPA then we only need to add streaming code for it. This
should be straightforward and there is no need to add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105275
--- Comment #6 from Jan Hubicka ---
as discussed in PR111551 the SPEC train run does not include hottest loop of
imagick (in ref loop), so we optimize it for size (in particular disable
vectorization) and get poor performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113646
--- Comment #7 from Jan Hubicka ---
Details are in PR111551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118551
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113646
--- Comment #6 from Jan Hubicka ---
The problem is that the internal loop in hottest function changes between train
and ref run (train run uses different variant of the loop). This disables
vectorization of the loop believed to be cold causing -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119298
--- Comment #15 from Jan Hubicka ---
I made sily stand-alone test:
long test[4];
__attribute__ ((noipa))
void
foo (unsigned long a, unsigned long b, unsigned long c, unsigned long d)
{
test[0]=a;
test[1]=b;
test[2]=c;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119298
--- Comment #14 from Jan Hubicka ---
> > I am OK with using addss cost of 3 for trunk&release branches and make this
> > more precise next stage1.
>
> That's what we use now? But I still don't understand why exactly
> 538.imagick_r regresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119298
--- Comment #12 from Jan Hubicka ---
> Btw, it was your r8-4018-gf6fd8f2bd4e9a9 which added the FP vs. non-FP
> difference.
Yep, I know. With that patch I mostly wanted to limit redundancy of the
tables. The int/Fp difference was mostly based
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119298
--- Comment #7 from Jan Hubicka ---
Hmm, the sequence does not use + at all, but I think I know what is going on.
While the field is called addss it is used as an kitchen sink for all other
simple operations.
/* pmuludq under sse2, pmuld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119147
--- Comment #4 from Jan Hubicka ---
Re-benchmarked current trunk -flto -Ofast -march=native (base) and -flto
-Ofast -march=native + PGO (peak) on znver3
Estimated Estimated
Base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119147
--- Comment #3 from Jan Hubicka ---
With speculation_useful_p we now are able to constant propagate stride into
mc_chroma with PGO, but it does not help runtime.
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680055.html
solves the costi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119606
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
This is visible on:
https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=553.676.1
https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=553.675.1
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119368
--- Comment #5 from Jan Hubicka ---
Thinking of it more, I think enabling memory alternatives in
(define_insn "sse4_1_v4hiv4si2"
[(set (match_operand:V4SI 0 "register_operand" "=Yr,*x,v")
(any_extend:V4SI
(vec_select:V4HI
(m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119368
--- Comment #2 from Jan Hubicka ---
On this combiner fails to match:
Failed to match this instruction:
(set (subreg:V4SI (reg:V2DI 101 [ ]) 0)
(sign_extend:V4SI (vec_select:V4HI (mem:V8HI (reg:DI 106) [0 *x_3(D)+0 S16
A128])
(p
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
as mentioned in
https://www.root.cz/clanky/instrukcni-sady-simd-a-automaticke-vektorizace-provadene-prekladacem-gcc/nazory/#newIndex1
the following code runs faster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #13 from Jan Hubicka ---
And forgot to write. In case of strcmp I think we can use fnspec info we
already have at the time constructing callgraph to represent it as a read
rather than taking address. This would make things go bit sm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #12 from Jan Hubicka ---
Indeed at IPA level we track if address of a symbol is taken, but we do not
keep any extra info about how it may be used. It would be useful to track
1) if address is used only to read (to figure out readon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119147
Jan Hubicka changed:
What|Removed |Added
Last reconfirmed||2025-03-13
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118924
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
This seems to be at least partly caused by fact that ipa-cp does not clone
function with no hot calls. This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111551
--- Comment #4 from Jan Hubicka ---
>From gcov dump, the normal train run exercises loop:
742632: 2953: switch ( method ) {
742632: 2954:case ConvolveMorphology:
-: 2955:/* Weighted Average of pixels using r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111551
--- Comment #3 from Jan Hubicka ---
With LTO the situation seems pretty much the same
21.23% imagick_r_peak. imagick_r_peak.trunk-pgolto-Ofast-native-m64
[.] MorphologyApply.cold
14.30% imagick_r_peak. imagick_r_peak.trunk-nop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111551
Jan Hubicka changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119033
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
Jan Hubicka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
The following (artificial) testcase (pointed to me by Filip Hejsek) is
miscompiled at -O2, since we miss the fact that test3(3) overwrites b[0].
#include
struct foo
at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #5 from Jan Hubicka ---
I had patch to reduce max issue back to 4 (exactly because of the compile time
slowdown and because the way we model decoder we own't issue more than 4
instructions). Seems I forgot to push it, wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318
--- Comment #13 from Jan Hubicka ---
Thanks for running this through debugger
Breakpoint 2.2, profile_count::operator+= (this=0x76e7e888, other=...) at
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/profile-count.h:932
932
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118527
--- Comment #3 from Jan Hubicka ---
The reason why I did not implement profile fixups to cfgcleanup is that you can
not really fix the profile without knowing why it became inconsistent.
Consider situation where we have function
foo (int a)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318
--- Comment #6 from Jan Hubicka ---
Some profile inconsistencies are expected unless you use atomic counters since
Firefox uses threads.
Do you know why compatible_p returns false? It looks like mixing IPA and
function local profiles together..
||hubicka at gcc dot gnu.org
--- Comment #5 from Jan Hubicka ---
When push_back is visible to compiler as in suggested modified testcase:
#include
#include
void push_back(uint32_t const&) __attribute__((noinline));
struct big_integer
{
void push_back(uint32_t c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80641
--- Comment #18 from Jan Hubicka ---
With -O3 we now get:
int main ()
{
[local count: 114863531]:
return 0;
}
-O2 offlines destructors which prevents us from optimizing away new()
int main ()
{
void * D.27676;
int * c$_M_finish;
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80813
--- Comment #6 from Jan Hubicka ---
Patch to optimize operator[] to be again branchless posted
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672286.html
Main problem with auto-generating bt is that it needs change of conditional
from C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26388
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117638
--- Comment #4 from Jan Hubicka ---
Both with assertions or without we offline _M_default_append which would be
better inlined. It is because main is known to be called once.
One difference is that non-assertion clobbers the vectors prior const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86276
--- Comment #2 from Jan Hubicka ---
With -O3 we now do quite well.
_Z4goodv:
.LFB1248:
.cfi_startproc
ret
.cfi_endproc
.LFE1248:
.size _Z4goodv, .-_Z4goodv
.p2align 4
.globl _Z3badv
.typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117639
--- Comment #3 from Jan Hubicka ---
With -O3 -std=c++20
https://godbolt.org/z/3WKnn8rax
we inline but still get stuck on loop calling log and modifying errno.
Without -std=c++20 we reach --param max-inline-insns-auto. We need --param
max-inlin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80813
--- Comment #5 from Jan Hubicka ---
Combine constructs:
(set (reg:CCZ 17 flags)
(compare:CCZ (zero_extract:DI (mem:DI (plus:DI (mult:DI (reg:DI 111 [ _8 ])
(const_int 8 [0x8]))
(reg/f:DI 112 [
v_2(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80813
--- Comment #4 from Jan Hubicka ---
Bit_reference constructor takes mask and not bit position.
_GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
reference
operator[](size_type __n)
{
__glibcxx_requires_subscript(__n);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80813
--- Comment #3 from Jan Hubicka ---
OK, so the horrid codegen is because bvector's [] operator is imlemented using
iterator:
return begin()[__n];
iterator's [] operator is implemented using:
_GLIBCXX20_CONSTEXPR
void
_M_incr(ptrdif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80813
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Summary|x86:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109440
--- Comment #3 from Jan Hubicka ---
I believe that since v is constructed and passed by invisible refernece in the
caller, we would need to know constructors of std::vector and prove that they
do not make &v to escape to global memory, so foo ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90436
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #14 from Jan Hubicka ---
Jonathan, is there some problem with your patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110378
--- Comment #10 from Jan Hubicka ---
Martin, I think this is fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
Bug 109849 depends on bug 110287, which changed state.
Bug 110287 Summary: _M_check_len is expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110287
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110287
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
++
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
meta-bug for code quality problems of std::vector.
I made statistic of use of std::vector in clang binary counting number of
occurrences of abstract instances of these functions in debug
||2024-12-15
Status|UNCONFIRMED |NEW
CC||hubicka at gcc dot gnu.org
--- Comment #4 from Jan Hubicka ---
We seems to spend most of time sorting PHI edges
#0 0x0231f835 in mergesort (in=,
c=0x7fffd530, n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86701
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #5
|NEW
CC||hubicka at gcc dot gnu.org,
||mjambor at suse dot cz
Last reconfirmed||2024-12-15
See Also||https://gcc.gnu.org/bugzill
|1
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #4 from Jan Hubicka ---
patch posted here
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671137.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
--- Comment #16 from Jan Hubicka ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671599.html
optimizes the string constructors. Having strlen pass catching more cases
would be nice, too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
Jan Hubicka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #15 from Jan Hubicka ---
Original testcase is solved by
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671599.html
We still won't optimize longer strings because _M_create is not inline.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103827
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94960
--- Comment #10 from Jan Hubicka ---
Note that passing function body to middle-end does not only enable inlining,
but other optimizations too. Often ipa-modref is able to summarize side effects
of the function and enables more optimization, since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #35 from Jan Hubicka ---
On
#include
bool test1(const std::vector& in) {
return in == std::vector{42};
}
we produce:
bool test1 (const struct vector & in)
{
bool _12;
int * _13;
int * _14;
long int _24;
unsigned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93921
Jan Hubicka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #14 from Jan Hubicka ---
Declaring _S_create and _M_create inline indeed helps a little:
diff --git a/libstdc++-v3/include/bits/basic_string.h
b/libstdc++-v3/include/bits/basic_string.h
index 17b973c8b45..d73a61abe5b 100644
--- a/lib
1 - 100 of 1577 matches
Mail list logo
