--- Comment #26 from davidxl at gcc dot gnu dot org 2010-08-31 17:45
---
Good observation re. the number of IVs in the final set. This usually points to
some problem/bug in the cost function. I briefly looked at this case -- it
indeed exposes two more bugs in the cost model:
1) the
--- Comment #25 from davidxl at gcc dot gnu dot org 2010-08-30 16:41
---
(In reply to comment #24)
> (In reply to comment #20)
> > (In reply to comment #16)
> > > adjust summary according to the last timings
> > >
> >
> > I am surprised to see
--- Comment #21 from davidxl at gcc dot gnu dot org 2010-08-30 03:19
---
(In reply to comment #17)
> tree iv optimization : 32.57 (20%) usr 0.10 ( 5%) sys 32.73 (20%) wall
> 322095 kB (18%) ggc
>
>
> 20% is still completely unreasonable for IV optimization.
--- Comment #20 from davidxl at gcc dot gnu dot org 2010-08-30 03:10
---
(In reply to comment #16)
> adjust summary according to the last timings
>
I am surprised to see such big differences between trunk and previous releases.
Compiling this test case with the those options
--- Comment #10 from davidxl at gcc dot gnu dot org 2010-08-28 06:00
---
fixed in r163610.
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from davidxl at gcc dot gnu dot org 2010-08-27 17:01 ---
Will take a look
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from davidxl at gcc dot gnu dot org 2010-07-30 17:23 ---
Seems -Os specific -- also reproducible on x86. With -O2, the result is
expected.
David
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from davidxl at gcc dot gnu dot org 2010-07-29 17:21 ---
Fixed in r162687
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from davidxl at gcc dot gnu dot org 2010-07-29 05:51 ---
The problem is that before the ivopt patch, the ivopt patch introduced a iv
candidate that is unconditionally initialized with b:
ivtmp_xxx = b (D);
After the patch, this assignment no longer exists, and the use
--- Comment #4 from davidxl at gcc dot gnu dot org 2010-07-19 16:34 ---
Fixed in r162310.
David
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from davidxl at gcc dot gnu dot org 2010-07-14 04:12 ---
This seems to be specific to powerpc.
Could you attach the dump files with options:
-O2 -Wuninitialized -fdump-tree-cddce2 -fdump-tree-uninit-details
Thanks,
David
(In reply to comment #0)
> Subject testc
--- Comment #3 from davidxl at gcc dot gnu dot org 2010-04-22 17:04 ---
(In reply to comment #2)
> (In reply to comment #1)
> >
> > so it doesn't consider the struct with the array for total scalarization
> > for some reason. Martin?
> >
>
> Wel
--- Comment #1 from davidxl at gcc dot gnu dot org 2010-04-21 00:29 ---
(In reply to comment #0)
> When compiling the source with "-Wall -O", gcc gives the following warning:
>
> % gcc -c -Wall -O gcc_test.c
> gcc_test.c: In function ?functionLeon?:
> gcc_test.
--- Comment #8 from davidxl at gcc dot gnu dot org 2010-04-21 00:27 ---
(In reply to comment #2)
> Note this is not fully a regression but really a progression.
> What is happening now is only partial optimizations is happen before the
> warning to happen.
>
> >I wa
--- Comment #11 from davidxl at gcc dot gnu dot org 2010-04-20 23:55
---
(In reply to comment #2)
> (In reply to comment #1)
> > check() can return 1 on the first call and 0 on the second and if *argv is
> > NULL
> > then then "bug" will be used unin
--- Comment #13 from davidxl at gcc dot gnu dot org 2010-02-03 22:05
---
(In reply to comment #12)
> Btw, a destructor call also changes the vtbl pointer.
>
ctors, dtors, wrapper function calls etc are all handled. Detailed write up
will be available at some point. To put it a
--- Comment #11 from davidxl at gcc dot gnu dot org 2010-02-03 21:55
---
(In reply to comment #9)
> Ah, "Set aside the standard". Another user who wants to make up his own
> semantics for a standardized language. No, no, and damn no.
>
Of course, things like thi
--- Comment #8 from davidxl at gcc dot gnu dot org 2010-02-03 21:44 ---
(In reply to comment #7)
> It is valid to use placement new to construct a more or less derived type
> which would change the vtable pointer.
>
> Thus I think this bug is still invalid.
>
How did
--- Comment #6 from davidxl at gcc dot gnu dot org 2010-02-03 18:30 ---
See discussions in http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00138.html
about changing dynamic types using placement new -- it is basically not allowed
-- so the optimization is valid.
David
--
davidxl at
--- Comment #3 from davidxl at gcc dot gnu dot org 2009-12-23 19:37 ---
This bug is ARM specific (thumb) mode. In x86, the hoisting is unnecessary as
the move instruction support the imm form.
The issue here is more in the GIMPLE canonicalization (target specific). In
this case, the
--- Comment #2 from davidxl at gcc dot gnu dot org 2009-12-09 18:07 ---
Fixed in r155111.
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davidxl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41038
s: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: davidxl at gcc dot gnu dot org
ReportedBy: davidxl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41012
--- Comment #8 from davidxl at gcc dot gnu dot org 2009-03-27 18:28 ---
See r145118 for the fix.
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from davidxl at gcc dot gnu dot org 2009-03-27 18:25 ---
See SVN revision 145121 for the fix.
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from davidxl at gcc dot gnu dot org 2009-03-25 23:10 ---
Created an attachment (id=17542)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17542&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39557
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davidxl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39557
--- Comment #6 from davidxl at gcc dot gnu dot org 2009-03-24 21:33 ---
(In reply to comment #4)
> Btw, it shouldn't really happen that we are not allowed to copyprop PHI
> arguments. It hints at some inconsistency in the IL instead.
>
This sounds good.
David(In reply
--- Comment #5 from davidxl at gcc dot gnu dot org 2009-03-24 21:25 ---
(In reply to comment #3)
> It might be better to place the check after the loop (and put an assert in
> set_copy_of_val that triggers the copy may not happen).
>
This sounds good.
David
--
http://gc
--- Comment #2 from davidxl at gcc dot gnu dot org 2009-03-24 17:51 ---
Created an attachment (id=17539)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17539&action=view)
patch file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39548
--- Comment #1 from davidxl at gcc dot gnu dot org 2009-03-24 17:50 ---
Created an attachment (id=17538)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17538&action=view)
Test case
--
davidxl at gcc dot gnu dot org changed:
What|
t gcc dot gnu dot org
ReportedBy: davidxl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39548
--- Comment #3 from davidxl at gcc dot gnu dot org 2008-11-22 00:35 ---
(In reply to comment #2)
> (In reply to comment #0)
> > For this function:
> > int test (int a, int b, int c, int g)
> > {
> > int d, e;
> > if (a)
> > d = b * c;
&g
--- Comment #6 from davidxl at gcc dot gnu dot org 2008-06-05 17:37 ---
(In reply to comment #5)
> Patch at http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00268.html
>
Thanks -- same as my local workaround.
David
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36438
--- Comment #1 from davidxl at gcc dot gnu dot org 2008-06-05 06:41 ---
cse1 (RTL) does some expression simplification on the fly such as
t = x << 4
r = t << 4
==>
r = x << 8
However for mmx shift operation, the mode (V1DI) for the const folding is
illega
: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davidxl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36438
--- Comment #15 from davidxl at gcc dot gnu dot org 2008-06-04 17:34
---
(In reply to comment #14)
> We do the exact opposite - type-based rules override points-to must-alias
> information (or really may-alias information). Also for the proposed scheme
> to work you need to
--- Comment #13 from davidxl at gcc dot gnu dot org 2008-06-04 16:48
---
(In reply to comment #12)
> Interesting things start to happen once you inline allocator functions as
> well.
> See PR29286 and PR33407 which we still don't handle 100% correct.
>
I browsed thr
38 matches
Mail list logo
