https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61225
--- Comment #16 from Zhenqiang Chen ---
Still in discussions in two threads about Combine and Compare-elim.
[PATCH] Fix PR 61225
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00558.html
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00577.html
ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64015
--- Comment #7 from Zhenqiang Chen ---
Sorry for blocking your benchmark tests. I had reverted the ccmp patch.
I will rework the patch based on Richard Henderson's comments:
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03100.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64015
--- Comment #5 from Zhenqiang Chen ---
It seams you always win with ccmp. Please go ahead for your patch and make sure
the following case work.
int
test (unsigned short a, unsigned char b)
{
return a > 0xfff2 && b > 252;
}
Thanks!
-Zhenqiang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64015
--- Comment #2 from Zhenqiang Chen ---
You force it to register? In fact, I tend to not force it to register in
gen_ccmp_next, since it will introduce more overhead for ccmp, which
performance maybe worse.
My patch to fix the issue is at:
https:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61225
--- Comment #15 from Zhenqiang Chen ---
Thank you for the reminder. I will rework the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63917
--- Comment #3 from Zhenqiang Chen ---
Root cause: r217646 enhances ifcvt to handle cbranchcc4 instruction. But ifcvt
does not check whether an insn will clobber CC or not, when moving it before
the cbranchcc4 instruction.
I will work out a patc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63917
--- Comment #2 from Zhenqiang Chen ---
Thanks for the report. I can reproduce the FAIL on IA32. Since the patch does
not impact on -O0, it seams some library functions are wrong. I will
investigate it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63743
--- Comment #4 from Zhenqiang Chen ---
(In reply to Jakub Jelinek from comment #3)
> (In reply to Zhenqiang Chen from comment #2)
> > (In reply to Jakub Jelinek from comment #1)
> > > Were we swapping operands before? I mean, if you rewrite the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63743
--- Comment #2 from Zhenqiang Chen ---
(In reply to Jakub Jelinek from comment #1)
> Were we swapping operands before? I mean, if you rewrite the testcase to
> swap the * arguments in the source, did you get the same more efficient code
> in the
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhenqiang.chen at arm dot com
Created attachment 33887
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33887&action=edit
test case
Root cause: the fold_stmt swaps the operands, which l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #11 from Zhenqiang Chen ---
> Added updated CSiBE benchmark for GCC 4.8, GCC 4.9 and trunk.
> It's obvious that excluding ip gives shorted code.
> Then there is something on trunk that makes some project become very large,
> which sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63210
--- Comment #4 from Zhenqiang Chen ---
(In reply to Ramana Radhakrishnan from comment #3)
> Fixed is it? And does it fail in GCC 4.9 ?
Fixed on trunk. Same fail in GCC 4.9.
It is a performance issue. Do you think it is OK for 4.9?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302
--- Comment #19 from Zhenqiang Chen ---
(In reply to John David Anglin from comment #18)
> Hi Zhenqiang,
>
> Do you plan to submit patch to gcc-patches soon?
Yes. It is in internal review process. I hope to send out it this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302
--- Comment #14 from Zhenqiang Chen ---
Created attachment 33608
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33608&action=edit
patch
After investigation, I found I mis-use tree_log2.
Please try the attached patch. If it works, I will r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302
--- Comment #13 from Zhenqiang Chen ---
For 4.9, some function optimizes the code as:
Optimizing range tests x_2 -[-2147483648, -2147483648] and -[0, 0]
into (x_2 & 2147483647) != 0
For trunk, optimize_range_tests_diff optimizes the code as:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302
--- Comment #10 from Zhenqiang Chen ---
(In reply to dave.anglin from comment #8)
> On 28-Sep-14, at 10:34 AM, dave.anglin at bell dot net wrote:
>
> > This is what I see on the trunk, but 4.9 is wrong. Possibly, there is
> > a transformation
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302
--- Comment #6 from Zhenqiang Chen ---
I double checked the function optimize_range_tests_diff. Overall, I think it
does the right thing. X86 and ARM work correctly. The ldil.c.169t.optimized is
:
x_2 = ival_1(D) & -2147481601;
_8 = x_2 +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63210
--- Comment #1 from Zhenqiang Chen ---
Here is a workaround patch to show the point.
diff --git a/gcc/ira-color.c b/gcc/ira-color.c
index e2ea359..1573fb5 100644
--- a/gcc/ira-color.c
+++ b/gcc/ira-color.c
@@ -1709,6 +1709,8 @@ assign_hard_reg (
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhenqiang.chen at arm dot com
Here is a case shown ira does not select the best register compared with gcc
4.8 for ARM Cortex-M0 with options:
-Os -mthumb -mcpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535
Zhenqiang Chen changed:
What|Removed |Added
CC||zhenqiang.chen at arm dot com
20 matches
Mail list logo
