--- 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
--- 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 such big differences between trunk and previous
--- 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 on my
--- 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.
There was a patch
--- 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 testcase
--- 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?
Well, that was a deliberate decision when fixing PR
--- 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 uninitialized.
right, but this doesn't matter
--- 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 was unable to reduce
--- 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.c:11: warning: ?reference? may
--- 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
--- 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 you reach
--- 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 this can be brought up
--- 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 simple
--- 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
--- 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
--- 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 #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
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 #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=17542action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39557
--- 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=17538action=view)
Test case
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
--- 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=17539action=view)
patch file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39548
--- 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://gcc.gnu.org
--- 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 to comment #4
--- 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;
else
d = b - c;
e = b * c + g;
return d
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 #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
illegal -- resulting in ICE
--- 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 #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 through the two bugs
--- 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 guarantee
35 matches
Mail list logo
