++
Assignee: unassigned at gcc dot gnu.org
Reporter: wmi at google dot com
Target Milestone: ---
For the testcase 1.cxx:
#include
int main() {
static const char* kNumericAnchor ="(\\$|usd)(usd|\\$|to|and|up
to|[0-9,\\.\\
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443
--- Comment #13 from wmi at google dot com ---
Use the extracted testcase vogt contributed. Here is some digging about why
rtx_refs_may_alias_p returns noalias for the load and store:
(gdb) c
Continuing.
Breakpoint 3, rtx_refs_may_alias_p (x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443
--- Comment #12 from wmi at google dot com ---
Yes, I agree it is a problem that memrefs_conflict_p doesn't take effect. But I
am still wondering even if memrefs_conflict_p doesn't take effect, the alias
oracle query in rtx_refs_m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443
--- Comment #6 from wmi at google dot com ---
(In reply to Dominik Vogt from comment #3)
> I think the Rtl in comment 1 ist correct. Note that "i" is stored at
> 0x.xx00 and "j" is stored at 0x.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443
--- Comment #2 from wmi at google dot com ---
Another problem is found in true_dependence_1 in alias.c. true_mem_addr or
true_x_addr got after calling get_addr may be used as inputs of
memrefs_conflict_p. However memrefs_conflict_p expects to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443
--- Comment #1 from wmi at google dot com ---
Seems the patch makes some problem exposed.
For the testcase 1.cxx below:
typedef struct A {
unsigned i : 8;
unsigned j : 24;
} A;
void foo(A *a) {
a->i = 3;
a->j = 5;
}
The rtl gen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65474
--- Comment #3 from wmi at google dot com ---
Thanks. You are right. I wrote a microbenchmark (attached), and tested it on
different intel microarchitectures.
westmere:
1.gcc.out:19.42
1.llvm.out: 19.32
sandybridge:
1.gcc.out:18.61
1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65474
--- Comment #2 from wmi at google dot com ---
Created attachment 35069
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35069&action=edit
microbench
Assignee: unassigned at gcc dot gnu.org
Reporter: wmi at google dot com
int foo(int x) {
return __builtin_abs(x);
}
~/workarea/gcc-r221398/build/install/bin/gcc -O2 -S 1.c -o 1.gcc.s
.cfi_startproc
movl%edi, %edx
movl%edi, %eax
sarl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64557
--- Comment #1 from wmi at google dot com ---
The experimental patch is to call get_addr for VALUE of base before plus other
constant, when creating mem_addr for dependence check and for store_info.
bootstrap and regression on x86_64-linux-gnu
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wmi at google dot com
We saw a bug in dse2 after porting the patch
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01209.html from gcc-4_9 to
google-4_9 branch. From the
Assignee: unassigned at gcc dot gnu.org
Reporter: wmi at google dot com
CC: davidxl at gcc dot gnu.org, hubicka at gcc dot gnu.org
We have a program like this:
A() {// hot func
...
}
B() {
A();// very hot
if (i) {
A(); // very cold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63970
--- Comment #6 from wmi at google dot com ---
The patch was committed to trunk at r217973.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63970
--- Comment #4 from wmi at google dot com ---
(In reply to Jan Hubicka from comment #3)
> Created attachment 34047 [details]
> Patch
>
> Something like this (untested) may work
Thanks! I tested your patch after minor change. It pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63970
--- Comment #1 from wmi at google dot com ---
> I think we need to keep the functions but do not need to account for them in
> the unit size if we otherwise could remove them
>
> Richard.
But there is code in
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wmi at google dot com
CC: davidxl at google dot com, dehao at google dot com,
hubicka at gcc dot gnu.org, rguenth at gcc dot
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wmi at google dot com
Created attachment 33730
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33730&action=edit
testcase 1.c
For program with many insns like "a = b + c", where operands &qu
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wmi at google dot com
CC: vmakarov at gcc dot gnu.org
Created attachment 33700
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33700&action=edit
testcase 1.cxx
For the testcase 1.cxx attached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61776
--- Comment #6 from wmi at google dot com ---
(In reply to davidxl from comment #5)
> (In reply to wmi from comment #4)
> > Can we move the pure/const resetting loop to an earlier place: inside
> > branch_prob , after instrument_e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61776
--- Comment #4 from wmi at google dot com ---
Can we move the pure/const resetting loop to an earlier place: inside
branch_prob , after instrument_edges and before gsi_commit_edge_inserts (where
stmt_ends_bb_p is checked), so that
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wmi at google dot com
CC: rguenth at gcc dot gnu.org
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61493
wmi at google dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61493
--- Comment #3 from wmi at google dot com ---
Fix a typo in the first post.
$~/workarea/gcc-r211604/build/install/bin/g++ -O2 1.cxx
$./a.out
not equal
$~/workarea/gcc-r211604/build/install/bin/g++ -O0 1.cxx
$./a.out
equal
$~/workarea/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61493
--- Comment #1 from wmi at google dot com ---
Created attachment 32931
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32931&action=edit
testcase
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wmi at google dot com
1.cxx is attached.
$~/workarea/gcc-r211604/build/install/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/google/home/wmi/workarea/gcc-r211604/build/install/bin/g++
COLLECT_LTO_WRAPPER
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wmi at google dot com
Testcase 1.c:
int a, b, c, d, e, cond;
void foo() {
int r1, r2, r3;
r1 = b;
r2 = d;
if (__builtin_expect(cond > 3, 0)) {
e = e * 5;
c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206
--- Comment #7 from wmi at google dot com ---
After looking into the problem more, I found IVOPT may not be the root cause.
Even if IVOPT create a memory operand using two registers, if only the
following optimizations doesn't propagate the m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206
--- Comment #6 from wmi at google dot com ---
Created attachment 32328
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32328&action=edit
2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206
--- Comment #4 from wmi at google dot com ---
> On Fri, 14 Feb 2014, pinskia at gcc dot gnu.org wrote:
>
> > I think the real issue __FP_FRAC_SUB_4 needs to be fixed not to use
> > inline-asm
> > but normal C code. The
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206
--- Comment #2 from wmi at google dot com ---
This is a way to fix the problem. libgcc/soft-fp/op-4.h has provided a C
version of __FP_FRAC_SUB_4, but now it is overrided by the inline asm version
in config/i386/32/sfp-machine.h.
But the inline
Assignee: unassigned at gcc dot gnu.org
Reporter: wmi at google dot com
CC: rguenth at gcc dot gnu.org, shenhan at google dot com
Host: i386
Target: i386
Created attachment 32141
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58985
--- Comment #9 from wmi at google dot com ---
Backported r200720 to gcc 4.8 branch at r204660.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58985
--- Comment #4 from wmi at google dot com ---
This is the testcase problem. For cris-axis-elf target, gcc doesn't use subreg
of reg 31 for the above testcase, so it is ok to generate REG_EQUIV note for
reg 31.
I will send out a patch for it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57878
wmi at google dot com changed:
What|Removed |Added
CC||wmi at google dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57518
wmi at google dot com changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57518
--- Comment #1 from wmi at google dot com ---
post a candidate patch here:
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00748.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57459
--- Comment #6 from wmi at google dot com ---
continue the analysis in the first post, for the smallcase 1.c, the IR after
calling inherit_in_ebb in lra_inheritance for bb12 is:
(insn 289 47 48 12 (set (reg:SI 116 [79])
(reg:SI 121 [79
Assignee: unassigned at gcc dot gnu.org
Reporter: wmi at google dot com
Testcase:
char ip[10];
int total, total1;
void foo() {
int t;
t = ip[2];
total = t & 0x3;
}
Target: x86_64-linux-gnu
gcc version 4.9.0 20130529 (experimental) (GCC)
~/workarea/gcc-r199418/b
Assignee: unassigned at gcc dot gnu.org
Reporter: wmi at google dot com
Created attachment 30218
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30218&action=edit
small testcase
To reproduce the bug on using 1.c attached:
Target: x86_64-unknown-linux-gnu
gcc version 4.9.0 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57130
Bug #: 57130
Summary: Incorrect "and --> extract" conversion in combine
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55353
--- Comment #2 from wmi at google dot com 2012-11-19 05:54:44 UTC ---
Hi Kostya,
Ok, I will extract the change from the tsan patch and send out a
separate patch about it.
Regards,
Wei.
On Sun, Nov 18, 2012 at 9:20 PM
41 matches
Mail list logo
