https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41505
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
--- Comment #7 from law at redhat dot com 2009-09-30 14:47 ---
Subject: Re: GCC choosing poor code sequence for certain
stores (x86)
On 09/30/09 03:22, jakub at gcc dot gnu dot org wrote:
> --- Comment #6 from jakub at gcc dot gnu dot org 2009-09-30 09:22 ---
> For x86-64 we
--- Comment #6 from jakub at gcc dot gnu dot org 2009-09-30 09:22 ---
For x86-64 we perhaps want further checks for the size optimization - if the
scratch register is %r8d through %r15d, 3 byte xorl %r8d, %r8d and e.g. 3 byte
movl %r8d, (%rdx) won't be shorter than movl $0, (%rdx) which
--- Comment #5 from rth at gcc dot gnu dot org 2009-09-29 23:43 ---
Yeah, that looks right.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41505
--- Comment #4 from law at redhat dot com 2009-09-29 21:55 ---
Subject: Re: GCC choosing poor code sequence for certain
stores (x86)
On 09/29/09 15:18, rth at gcc dot gnu dot org wrote:
> --- Comment #3 from rth at gcc dot gnu dot org 2009-09-29 21:18 ---
> There are already
--- Comment #3 from rth at gcc dot gnu dot org 2009-09-29 21:18 ---
There are already peepholes for this, though the condition appears to be
slightly wrong for -Os. See i386.md:21121 :
(define_peephole2
[(match_scratch:SI 1 "r")
(set (match_operand:SI 0 "memory_operand" "")
--- Comment #2 from law at redhat dot com 2009-09-29 17:12 ---
I don't understand your comment Richard. Isn't it just something like this?
(define_peephole2
[(match_scratch:SI 2 "r")
(set (match_operand:SI 0 "memory_operand" "")
(match_operand:SI 1 "const_0_operand" ""))]
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-29 16:07 ---
difficult
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41505
