This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/32629] missing CSE for constant in registers / inefficient memset
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 11 Jun 2012 08:39:45 +0000
- Subject: [Bug rtl-optimization/32629] missing CSE for constant in registers / inefficient memset
- Auto-submitted: auto-generated
- References: <bug-32629-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32629
--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> 2012-06-11 08:39:45 UTC ---
On Sat, 9 Jun 2012, hubicka at ucw dot cz wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32629
>
> --- Comment #2 from Jan Hubicka <hubicka at ucw dot cz> 2012-06-09 22:17:07 UTC ---
> > I suppose doing the $0x0 optimization should be done post-reload.
> I was wondering how to implement this nice for some years already.... I don't
> see how this can be done without specialized pass, really, and the interface is
> probably going to be bit weird, since it is very weird property of x86
> instruction set that there are no stores with short immediate...
I wonder if we can use a peephole2 and DF information (and update it
on-the-fly). Thus, when seeing
mov $0, ...
mov $0, ...
transform it incrementally to
xor %eax, %eax
mov %eax, ...
mov $0, ...
and then have a 2nd peephole2 with higher priority that looks for
a register with zero content (eh ... that's the interesting part ;))
and do
xor %eax, %eax
mov %eax, ...
mov %eax, ...
I suppose we have the first peephole already - though we'd end up
with
xor %eax, %eax
mov %eax, ...
xor %eax, %eax
mov %eax, ...
and rely on postreload-cse to clean that up (which isn't run after
the peephole2 in postreload queue ...)
Richard.