public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/31358] New: IV-OPTs produces a weird MEM_REF
@ 2007-03-26 1:18 pinskia at gcc dot gnu dot org
2007-03-26 9:17 ` [Bug tree-optimization/31358] " rakdver at gcc dot gnu dot org
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-03-26 1:18 UTC (permalink / raw)
To: gcc-bugs
For:
int *f(int *a, int b, int c)
{
int i;
a --;
*a = 1;
for (i = 0;i<b;i+=c)
(a[i]) = 0;
return a;
}
----------------CUT----------------
I get in the final_cleanup:
MEM[index: ivtmp.35, offset: 4294967292] = 0;
And I noticed that ivtmp.29 is of type "long unsigned int" which seems wrong as
it is actually the pointer. I think this in the end could also cause PR 28690
too.
Anyways the assembly in the ends up to be:
L4:
add r9,r9,r5
li r2,0
subf r0,r5,r9
stw r2,-4(r3)
cmpw cr7,r4,r0
add r3,r3,r11
bgt+ cr7,L4
Which is bad, I will file a bug about not pulling out the "li r2, 0" in another
bug (that is a regression too). But we have an add and a sub -4 which is just
wrong. we should be able to use stwx instead which we did in 4.0.2.
--
Summary: IV-OPTs produces a weird MEM_REF
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31358
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/31358] IV-OPTs produces a weird MEM_REF
2007-03-26 1:18 [Bug tree-optimization/31358] New: IV-OPTs produces a weird MEM_REF pinskia at gcc dot gnu dot org
@ 2007-03-26 9:17 ` rakdver at gcc dot gnu dot org
2007-03-26 16:35 ` pinskia at gcc dot gnu dot org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: rakdver at gcc dot gnu dot org @ 2007-03-26 9:17 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from rakdver at gcc dot gnu dot org 2007-03-26 10:17 -------
(In reply to comment #0)
> For:
> int *f(int *a, int b, int c)
> {
> int i;
> a --;
> *a = 1;
> for (i = 0;i<b;i+=c)
> (a[i]) = 0;
> return a;
> }
> ----------------CUT----------------
> I get in the final_cleanup:
> MEM[index: ivtmp.35, offset: 4294967292] = 0;
>
>
> And I noticed that ivtmp.29 is of type "long unsigned int" which seems wrong as
> it is actually the pointer.
no, this is OK (whether it is a good design choice is another thing, I will
think about that).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31358
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/31358] IV-OPTs produces a weird MEM_REF
2007-03-26 1:18 [Bug tree-optimization/31358] New: IV-OPTs produces a weird MEM_REF pinskia at gcc dot gnu dot org
2007-03-26 9:17 ` [Bug tree-optimization/31358] " rakdver at gcc dot gnu dot org
@ 2007-03-26 16:35 ` pinskia at gcc dot gnu dot org
2007-03-26 21:27 ` pinskia at gcc dot gnu dot org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-03-26 16:35 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-26 17:35 -------
Even if this MEM is ok, we still get bad results as we have *(a+b-4) inside the
loop now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31358
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/31358] IV-OPTs produces a weird MEM_REF
2007-03-26 1:18 [Bug tree-optimization/31358] New: IV-OPTs produces a weird MEM_REF pinskia at gcc dot gnu dot org
2007-03-26 9:17 ` [Bug tree-optimization/31358] " rakdver at gcc dot gnu dot org
2007-03-26 16:35 ` pinskia at gcc dot gnu dot org
@ 2007-03-26 21:27 ` pinskia at gcc dot gnu dot org
2007-06-08 7:53 ` pinskia at gcc dot gnu dot org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-03-26 21:27 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-26 22:27 -------
3.2.3 produced:
.L6:
slwi 0,9,2
add 9,9,5
cmpw 0,9,4
stwx 11,3,0
bgelr- 0
b .L6
While 4.1.0 and above produces:
.L4:
add 9,9,5
stw 10,-4(3)
add 3,3,11
subf 0,5,9
cmpw 7,4,0
bgt 7,.L4
If we change "int *" to "char *" and set c to be 2, we get even worse code gen.
3.2.3:
.L9:
stbx 11,3,9
addi 9,9,2
bdnz .L9
blr
4.1.0:
.L4:
add 9,3,11
addi 11,11,2
cmpw 7,4,11
stb 0,-1(9)
bgt 7,.L4
What happened to bdnz and we are now doing *(r9+r3-1) = r0 inside the loop?
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to fail| |4.1.0 4.2.0 4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31358
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/31358] IV-OPTs produces a weird MEM_REF
2007-03-26 1:18 [Bug tree-optimization/31358] New: IV-OPTs produces a weird MEM_REF pinskia at gcc dot gnu dot org
` (2 preceding siblings ...)
2007-03-26 21:27 ` pinskia at gcc dot gnu dot org
@ 2007-06-08 7:53 ` pinskia at gcc dot gnu dot org
2007-08-06 5:59 ` pinskia at gcc dot gnu dot org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-06-08 7:53 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-08 07:52 -------
(In reply to comment #1)
> no, this is OK (whether it is a good design choice is another thing, I will
> think about that).
I actually have a fix for this issue (the MEM with just index: and offset:) but
it is going to wait until after the pointer_plus merge.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31358
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/31358] IV-OPTs produces a weird MEM_REF
2007-03-26 1:18 [Bug tree-optimization/31358] New: IV-OPTs produces a weird MEM_REF pinskia at gcc dot gnu dot org
` (3 preceding siblings ...)
2007-06-08 7:53 ` pinskia at gcc dot gnu dot org
@ 2007-08-06 5:59 ` pinskia at gcc dot gnu dot org
2008-03-11 9:38 ` rguenth at gcc dot gnu dot org
2008-03-11 9:47 ` rguenth at gcc dot gnu dot org
6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-08-06 5:59 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from pinskia at gcc dot gnu dot org 2007-08-06 05:58 -------
Yes this does cause some of PR 28690.
Anyways, mine.
A patch for this was posted at
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00006.html
I need to update it for the comments still.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
OtherBugsDependingO| |28690
nThis| |
AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2007-08-06 05:58:46
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31358
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/31358] IV-OPTs produces a weird MEM_REF
2007-03-26 1:18 [Bug tree-optimization/31358] New: IV-OPTs produces a weird MEM_REF pinskia at gcc dot gnu dot org
` (4 preceding siblings ...)
2007-08-06 5:59 ` pinskia at gcc dot gnu dot org
@ 2008-03-11 9:38 ` rguenth at gcc dot gnu dot org
2008-03-11 9:47 ` rguenth at gcc dot gnu dot org
6 siblings, 0 replies; 8+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-03-11 9:38 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from rguenth at gcc dot gnu dot org 2008-03-11 09:37 -------
Subject: Bug 31358
Author: rguenth
Date: Tue Mar 11 09:36:51 2008
New Revision: 133102
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133102
Log:
2008-03-11 Andrew Pinski <andrew_pinski@playstation.sony.com>
Richard Guenther <rguenther@suse.de>
PR tree-optimization/31358
* tree-ssa-loop-manip.c (create_iv): Call force_gimple_operand for
the step with a NULL_TREE.
* tree-ssa-loop-ivopts.c (find_bivs): Convert the step
to sizetype if type is a pointer type.
(add_candidate_1): Don't convert the base and step to
the generic type if the orginal type is a pointer type.
(add_iv_value_candidates): Use sizetype for the step
if type is a pointer type.
(cand_value_at): Likewise.
* tree-ssa-address.c (add_to_parts): Use POINTER_PLUS_EXPR
for pointer types.
* tree-affine.c (tree_to_aff_combination <POINTER_PLUS_EXPR>):
Don't convert the tem affine to the type.
(add_elt_to_tree): Use sizetype for the step if a pointer.
Use POINTER_PLUS_EXPR for pointers.
(aff_combination_to_tree): Use sizetype for the step if a
pointer.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-affine.c
trunk/gcc/tree-ssa-loop-ivopts.c
trunk/gcc/tree-ssa-loop-manip.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31358
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/31358] IV-OPTs produces a weird MEM_REF
2007-03-26 1:18 [Bug tree-optimization/31358] New: IV-OPTs produces a weird MEM_REF pinskia at gcc dot gnu dot org
` (5 preceding siblings ...)
2008-03-11 9:38 ` rguenth at gcc dot gnu dot org
@ 2008-03-11 9:47 ` rguenth at gcc dot gnu dot org
6 siblings, 0 replies; 8+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-03-11 9:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from rguenth at gcc dot gnu dot org 2008-03-11 09:46 -------
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31358
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2008-03-11 9:47 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-26 1:18 [Bug tree-optimization/31358] New: IV-OPTs produces a weird MEM_REF pinskia at gcc dot gnu dot org
2007-03-26 9:17 ` [Bug tree-optimization/31358] " rakdver at gcc dot gnu dot org
2007-03-26 16:35 ` pinskia at gcc dot gnu dot org
2007-03-26 21:27 ` pinskia at gcc dot gnu dot org
2007-06-08 7:53 ` pinskia at gcc dot gnu dot org
2007-08-06 5:59 ` pinskia at gcc dot gnu dot org
2008-03-11 9:38 ` rguenth at gcc dot gnu dot org
2008-03-11 9:47 ` rguenth at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).