--- Comment #22 from steven at gcc dot gnu dot org 2007-05-25 20:32 ---
With the current implementation of SEE it is almost impossible to make it work
on x86. You have to take into account the liveness of the flags register, and
there currently is no way to include that in the dataflow
--- Comment #21 from steven at gcc dot gnu dot org 2007-04-20 22:10 ---
Collection of important related links:
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00766.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437#c5
--
steven at gcc dot gnu dot org changed:
What|R
--- Comment #20 from steven at gcc dot gnu dot org 2007-04-20 21:58 ---
It is my intention to fix see.c to work on x86* hardware, so I'm taking this
bug.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from hjl at lucon dot org 2006-02-27 23:40 ---
Even with the new patch
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01994.html
I still got the same result. The new see pass won't touch
(insn:HI 13 9 14 2 (set (reg/v:SI 73 [ t ])
(mem/s:SI (symbol_ref:DI ("state
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|SUSPENDED |NEW
Last reconfirmed|2005-05-04 18:12:43 |2006-01-15 20:30:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-29
03:44 ---
New patch was posted:
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01769.html
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-27
13:36 ---
(In reply to comment #13)
> No, I didn't :-)
>
> So you suggest closing this as SUSPEND?
Yes. But note IBM haifa is going to submit a pass for this and has been
outlined before.
--
What|
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-27
10:24 ---
/me should read up on the amd64 instruction set first :-(
--
What|Removed |Added
Ass
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-27
10:23 ---
moron alert
--
What|Removed |Added
Status|RESOLVED|REOPENED
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-27
10:13 ---
More knowledgable sources than me say:
"[mov %eax, %eax ] is not nop. 32bit operations implicitly zero
extend, so this is zero extension. There is no movqzx."
--
What|Removed
--- Additional Comments From stevenb at suse dot de 2005-01-27 07:14
---
Subject: Re: Redundant instructions in loop optimization
On Thursday 27 January 2005 07:05, rth at gcc dot gnu dot org wrote:
> --- Additional Comments From rth at gcc dot gnu dot org 2005-01-27
> 06:05 -
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-27 06:05
---
Steven, you do realize this is essentially unfixable without a new pass that
optimially places widened operations, don't you?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17387
--- Additional Comments From hjl at lucon dot org 2005-01-27 04:03 ---
Gcc doesn't know/remember
movlS(,%rax,4), %eax
will zero extend to 64bit. I don't know you can touch only the lower
32bit bits.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17387
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-27
01:43 ---
GCC can't see that this is a NOP because of the zero_extend:
#(insn 34 30 37 (set (reg:DI 0 ax [orig:76 D.1460 ] [76])
#(zero_extend:DI (reg:SI 0 ax [orig:70 D.1460 ] [70]))) 111
{zero_extendsidi
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-27
01:36 ---
My first suspicion was the `register' keyword, but that's not it:
--
extern unsigned int S[];
extern unsigned int state[];
unsigned int
foo ()
{
un
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-27
01:27 ---
Uhm, right. OK then, lemme have a look.
--
What|Removed |Added
AssignedTo|unassigne
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24
18:52 ---
Confirmed again.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From hjl at lucon dot org 2005-01-24 18:17 ---
Looking at the mainline result, I still see "mov %eax, %eax", which was
the original bug report for mainline.
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-23
13:35 ---
Mainline today produces:
foo:
.LFB2:
xorl%eax, %eax
movl$4, %ecx
movl$state, %edx
.p2align 4,,7
.L2:
mov %eax, %eax
movlS(,%rax,4
--
What|Removed |Added
Severity|normal |enhancement
Last reconfirmed|-00-00 00:00:00 |2004-11-27 20:49:43
date|
20 matches
Mail list logo
