https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69377
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69442
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65768
--- Comment #3 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Tue Jun 2 22:53:15 2015
New Revision: 224048
URL: https://gcc.gnu.org/viewcvs?rev=224048&root=gcc&view=rev
Log:
gcc/ChangeLog:
2015-06-03 Kugan Vivekana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65768
kugan at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66554
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66554
--- Comment #2 from kugan at gcc dot gnu.org ---
can_fix_p is returining CODE_FOR_nothing for converting from tomode=V4SImode to
frommode=V4SFmode with branch 4.9. With trunk it is returning
CODE_FOR_fix_truncv4sfv4si2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66554
--- Comment #3 from kugan at gcc dot gnu.org ---
correction:
with 4.9 when it ICE we have:
Breakpoint 1, expand_fix (to=to@entry=0x765b5480, from=0x765b2000,
unsignedp=unsignedp@entry=0) at
/home/kugan/work/sources/gcc-fsf/4.9/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66554
--- Comment #6 from kugan at gcc dot gnu.org ---
-fno-tree-forwprop works.
forwprop propagates:
vect__11.22_96 = (vector(4) float) vect_c.21_94;
vect__13.24_98 = (vector(4) signed int) vect__11.22_96;
into:
vect__13.24_98 = (vector(4) signed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66554
--- Comment #8 from kugan at gcc dot gnu.org ---
Starting bisect now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64130
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64130
--- Comment #10 from kugan at gcc dot gnu.org ---
(In reply to Marc Glisse from comment #6)
> (In reply to kugan from comment #5)
> > I think it should be in from front-end?
>
> ?
Sorry for the confusing terminology.
for the c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65375
kugan at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64130
--- Comment #11 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Mon Jun 29 00:15:41 2015
New Revision: 225108
URL: https://gcc.gnu.org/viewcvs?rev=225108&root=gcc&view=rev
Log:
gcc/ChangeLog:
2015-06-29 Kugan Vivekana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66726
--- Comment #1 from kugan at gcc dot gnu.org ---
Created attachment 35888
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35888&action=edit
untested prototype patch
Hi Jeff,
Here is a patch (without debug dumps and not tesetd ful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66726
--- Comment #3 from kugan at gcc dot gnu.org ---
> really you should handle more
> than two arguments to phis.
I am not sure how we can handle phi stmt with more than two arguments here. Any
hints please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66726
--- Comment #5 from kugan at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #4)
> (In reply to kugan from comment #3)
> > > really you should handle more
> > > than two arguments to phis.
> > I am not sure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66759
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66726
--- Comment #8 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Sun Jul 12 11:22:42 2015
New Revision: 225722
URL: https://gcc.gnu.org/viewcvs?rev=225722&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:
2015-07-12 Kugan Vivekana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66726
--- Comment #11 from kugan at gcc dot gnu.org ---
Thanks for reporting. This test case is valid for targets that has branch cost
greater than 1.
One way to handle this is by disabling this for convections involving bool that
are part of branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66865
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66726
--- Comment #12 from kugan at gcc dot gnu.org ---
Created attachment 35976
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35976&action=edit
patch for tree-ssa-reassoc
Here is a prototype patch (to fix comment 9) that makes tree-ssa-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66865
--- Comment #4 from kugan at gcc dot gnu.org ---
Ok, I downloaded wine-1.7.47.tar.bz2 and built it with trunk gcc. What do I
have to do to reproduce this please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66865
--- Comment #12 from kugan at gcc dot gnu.org ---
(In reply to austinenglish from comment #5)
> (In reply to kugan from comment #4)
> > Ok, I downloaded wine-1.7.47.tar.bz2 and built it with trunk gcc. What do I
> > have to do to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66726
--- Comment #19 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Sun Jul 24 12:47:29 2016
New Revision: 238695
URL: https://gcc.gnu.org/viewcvs?rev=238695&root=gcc&view=rev
Log:
gcc/ChangeLog:
2016-07-24 Kugan Vivekana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71994
--- Comment #2 from kugan at gcc dot gnu.org ---
Patch to fix this is posted for review at
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01680.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71994
--- Comment #4 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Wed Jul 27 22:45:46 2016
New Revision: 238802
URL: https://gcc.gnu.org/viewcvs?rev=238802&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:
2016-07-28 Kugan Vivekana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71994
--- Comment #5 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Wed Jul 27 23:02:44 2016
New Revision: 238803
URL: https://gcc.gnu.org/viewcvs?rev=238803&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:
2016-07-28 Kugan Vivekana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68217
--- Comment #4 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Fri Jul 29 00:35:23 2016
New Revision: 238846
URL: https://gcc.gnu.org/viewcvs?rev=238846&root=gcc&view=rev
Log:
gcc/ChangeLog:
2016-07-29 Kugan Vivekana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72835
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72835
--- Comment #4 from kugan at gcc dot gnu.org ---
Looks like it was a latent issue. In rewrite_expr_tree, when re-associate
operands, we should reset range_info for the LHS. We don’t do that now.
Following patch fixes the test case.
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61839
--- Comment #3 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Sat Aug 20 01:18:09 2016
New Revision: 239637
URL: https://gcc.gnu.org/viewcvs?rev=239637&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:
2016-08-20 Kugan Vivekana
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
For testcase:
int foo (int i)
{
int x = i;
x = __builtin_abs (i);
x >>= 24;
if (x > 256)
return 0;
return x;
}
vrp1 dump is:
Val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77387
--- Comment #1 from kugan at gcc dot gnu.org ---
With :
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index e4d789b..2d1f4c8 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -3416,6 +3416,17 @@ extract_range_from_unary_expr_1 (value_range *vr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113698
--- Comment #4 from kugan at gcc dot gnu.org ---
Thanks for looking into this. The main reason we ere seeing performance issue
turned out to be due to glibc malloc issue in
https://sourceware.org/bugzilla/show_bug.cgi?id=30945
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #5 from kugan at gcc dot gnu.org ---
-O3 -fno-tree-vectorize and -O3 -fno-tree-vrp works. I looked at the ever
dump and it is not doing anything suspicious. Looks like range_info usage in
vectoriser is causing the problem.
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
For:
extern __attribute__((aligned(64))) int a[32000],b[32000];
void s1112(void)
{
for (int i = 32000 - 1; i >= 0
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
reduced test case:
typedef float real_t;
extern __attribute__((aligned(64))) real_t a[32000], b[32000];
void s255()
{
real_t x, y;
x = b[32000 -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #20 from kugan at gcc dot gnu.org ---
(In reply to Richard Sandiford from comment #19)
> (In reply to Richard Biener from comment #14)
> > Usually targets do have a limit on the actual length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116338
--- Comment #3 from kugan at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> The issue is the recurrence
>
>[local count: 10737416]:
> x_10 = b[31999];
> y_11 = b[31998];
>
>[local count: 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116338
--- Comment #5 from kugan at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
> You can try to see whether adding a SSA copy would make this supported, it
> seems not allowing a PHI is simply a missed feature.
We now f
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
See:
typedef float real_t;
extern __attribute__((aligned(64))) real_t a[32000];
real_t not_woring(struct args_t *func_args) {
int k, index;
int inc = 1;
real_t max, chksum
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
typedef int real_t;
extern __attribute__((aligned(64))) real_t a[32000],b[32000],c[32000],d[32000];
void s4117()
{
for (int i = 0; i
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
Created attachment 59057
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59057&action=edit
testcase
For a partally reduced code, I am seeing:
t.cpp:350:12: internal compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116626
--- Comment #1 from kugan at gcc dot gnu.org ---
Looks duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116569
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
Created attachment 57910
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57910&action=edit
testcase
Main loop in the attached test case is not vectoriz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114653
--- Comment #2 from kugan at gcc dot gnu.org ---
Thanks. I see the following in the log:
test.cpp:33:53: missed: not vectorized: relevant stmt not supported: _54 =
.MASK_LOAD (_53, 32B, _171);
test.cpp:22:19: missed: bad operation or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114653
--- Comment #3 from kugan at gcc dot gnu.org ---
For SVE mode in vect_analyze_loop_2, we have
(gdb) p min_vf
$15 = {coeffs = {4, 4}}
(gdb) p max_vf
$16 = 16
Thus maybe_lt (max_vf, min_vf)) is false. This results in bad data dependence.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114653
--- Comment #4 from kugan at gcc dot gnu.org ---
This particular loop has loop->safelen set to 16. Does this mean this can never
be loop vectorized for VLA?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114653
--- Comment #5 from kugan at gcc dot gnu.org ---
ddd for the :
ref_a:
_57 = D.4803[_20];
ref_b:
D.4803[_20] = _ifc__174;
We get DDR_ARE_DEPENDENT (ddr) == chrec_dont_know. Hence apply_safelen ().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114653
kugan at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 114653, which changed state.
Bug 114653 Summary: Not vectorizing the loop with openmp reduction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114653
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #9 from kugan at gcc dot gnu.org ---
Looking at the options, looks to me that making loop->safelen a poly_in is the
way to go. (In reply to Jakub Jelinek from comment #4)
> The OpenMP safelen clause argument is a scalar integ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #10 from kugan at gcc dot gnu.org ---
Created attachment 57946
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57946&action=edit
patch
patch to make loop->safelen a poly_int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #12 from kugan at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #11)
> (In reply to kugan from comment #9)
> > Looking at the options, looks to me that making loop->safelen a poly_in is
> > the way t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #18 from kugan at gcc dot gnu.org ---
Also, can we set INT_MAX when there is no explicit safelen specified in OMP.
Something like:
--- a/gcc/omp-low.cc
+++ b/gcc/omp-low.cc
@@ -6975,14 +6975,11 @@ lower_rec_input_clauses (tree
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
Patch [PATCH 1/4] Relax COND_EXPR reduction vectorization SLP restriction seem
to cause ICE while building TSVC_2
Reduced test:
cat tsvc_vec.i
void dummy();
void s331() {
int j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115383
--- Comment #5 from kugan at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
> Created attachment 58378 [details]
> patch
>
> I'm testing this, but I do not have hardware to test correctness (and qemu
> not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115383
--- Comment #6 from kugan at gcc dot gnu.org ---
(In reply to kugan from comment #5)
> (In reply to Richard Biener from comment #4)
> > Created attachment 58378 [details]
> > patch
> >
> > I'm testing this, bu
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Created attachment 57275
--> https://gcc.gnu.
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
5022.gcc is meicompiling for aarch64 with -O3 -Wl,-z,muldefs -lm
-fallow-argument-mismatch -fpermissive -fstack-arrays -flto
-Wl,--sort-section=name -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115450
--- Comment #2 from kugan at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
> >[r15-1006-gd93353e6423eca] Do single-lane SLP discovery for reductions
>
>
> Interesting because PR 115256 bisect it to an earlier p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116785
--- Comment #14 from kugan at gcc dot gnu.org ---
(In reply to Richard Biener from comment #13)
> Did it help?
Thanks for the quick Fix. This commit brings back most of the regression.
Please note that the current trunk seems to be broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117050
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115258
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116785
--- Comment #10 from kugan at gcc dot gnu.org ---
Created attachment 59186
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59186&action=edit
reduced test (second attempt)
Sorry about the test case. Here is another attempt at reducing.
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
Some of the loops in RAJAPerf are not vectored with the change. This results in
~64% regression for this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116785
--- Comment #2 from kugan at gcc dot gnu.org ---
Created attachment 59155
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59155&action=edit
creduce reduced file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116785
--- Comment #1 from kugan at gcc dot gnu.org ---
Created attachment 59154
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59154&action=edit
preprocessed file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117782
--- Comment #9 from kugan at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #8)
> Can you try again now that PR 117350 has actually been pushed?
Thanks. This fixes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117782
kugan at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117782
--- Comment #6 from kugan at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #5)
> Specifically see
> https://inbox.sourceware.org/gcc-patches/20241031204043.3231740-1-ak@linux.
> intel.com/T/#u .
>
> You need to
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
Created attachment 59704
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59704&action=edit
testcase
(gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117782
--- Comment #1 from kugan at gcc dot gnu.org ---
Created attachment 59705
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59705&action=edit
profile gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117782
--- Comment #2 from kugan at gcc dot gnu.org ---
--- a/gcc/cp/mangle.cc
+++ b/gcc/cp/mangle.cc
@@ -1194,6 +1194,7 @@ write_unscoped_name (const tree decl)
in a local function scope. A lambda can also be mangled in the
scope of
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
Created attachment 60058
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60058&action=edit
testcase
ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120614
--- Comment #8 from kugan at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #6)
> Also BTW, I think it is useful to do the dumps wth -details-blocks since
> that also dumps BB count inconsistencies caused by AutoFDO th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120614
--- Comment #7 from kugan at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #6)
> Also BTW, I think it is useful to do the dumps wth -details-blocks since
> that also dumps BB count inconsistencies caused by AutoFDO th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120614
--- Comment #10 from kugan at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #9)
> > > as mentioned by Andrew, it is important to clone and also resolve indirect
> > > calls. Those auto-FDO 0 may prevent it from happ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120614
--- Comment #11 from kugan at gcc dot gnu.org ---
This specific ICE seems to be fixed with
e416c8097fc87513e05c2d104c63488f733758c0
Thanks for the fix.
I am now seeing one in:
x264_src/common/mc.c: In function 'mc_weight_w16.part.0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120614
--- Comment #12 from kugan at gcc dot gnu.org ---
(In reply to kugan from comment #11)
> This specific ICE seems to be fixed with
> e416c8097fc87513e05c2d104c63488f733758c0
> Thanks for the fix.
>
> I am now seeing one in:
>
-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: kugan at gcc dot gnu.org
Target Milestone: ---
525.x264_r is ~30% slower with AutoFDO compared to PGO.
Functions that contribute most to the regressions are:
x264_pixel_sad_x4_16x16.lto_priv.0
x264_pixel_sad_x4_8x8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120614
--- Comment #3 from kugan at gcc dot gnu.org ---
Created attachment 61610
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61610&action=edit
x264_pixel_sad_x4_16x16.diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120614
--- Comment #4 from kugan at gcc dot gnu.org ---
x264_pixel_sad_x4_16x16.diff is at -O3 without -flto. Function level profiling
is same even with -flto.
x264_pixel_sad_x4_16x16 total:18508 head:4627
0: 4627
0.1: 0
0.2: 0
0.3: 0
0.4
201 - 284 of 284 matches
Mail list logo
