--- Comment #18 from bernds at gcc dot gnu dot org 2010-08-16 23:49 ---
I'm seeing some strange situations where this code is unnecessarily producing
lea insns even when not tuning for Atom.
This code looks very strange. I don't understand why we aren't splitting to a
lea pattern anymo
--- Comment #19 from bernds at gcc dot gnu dot org 2010-08-16 23:51 ---
Created an attachment (id=21497)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21497&action=view)
A patch which should produce more add insns
In other words, don't we at least need this patch to avoid generati
--- Comment #20 from hjl dot tools at gmail dot com 2010-08-17 00:10
---
(In reply to comment #18)
> I'm seeing some strange situations where this code is unnecessarily producing
> lea insns even when not tuning for Atom.
>
> This code looks very strange. I don't understand why we are
--- Comment #21 from hjl dot tools at gmail dot com 2010-08-17 00:11
---
(In reply to comment #19)
> Created an attachment (id=21497)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21497&action=view) [edit]
> A patch which should produce more add insns
>
> In other words, don't we
--- Comment #22 from bernds at gcc dot gnu dot org 2010-08-17 00:16 ---
I was looking at Spec2k/254.gap/integer.s which has many examples, all of the
form.
- leal(%ecx,%eax), %eax
+ addl%ecx, %eax
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
--- Comment #23 from hjl dot tools at gmail dot com 2010-08-17 03:46
---
Created an attachment (id=21499)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21499&action=view)
A different patch
We added the 2rd alternative to "*add_1" for Atom
so that we always use add instead lea. It
--- Comment #24 from bernds at gcc dot gnu dot org 2010-08-17 09:47 ---
I think that's beginning to look reasonable. So the problem was that without
alternative 2, such an add would match alternative 3 instead and be split?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
--- Comment #25 from hjl dot tools at gmail dot com 2010-08-17 14:47
---
(In reply to comment #24)
> I think that's beginning to look reasonable. So the problem was that without
> alternative 2, such an add would match alternative 3 instead and be split?
>
Yes.
--
http://gcc.gnu
--- Comment #26 from ubizjak at gmail dot com 2010-08-18 20:13 ---
Splitting to LEA was fixed in r163351 [1] with patch at [2].
[1] http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00562.html
[2] http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01394.html
--
ubizjak at gmail dot com changed:
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-08 22:00 ---
It may be broken by revision 160394:
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00307.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-09 00:52 ---
(In reply to comment #1)
> It may be broken by revision 160394:
>
> http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00307.html
>
This change moved
(insn:TI 11 41 12 pr44470.i:15 (parallel [
(set (reg:SI 1 dx
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-09 00:59 ---
The old scheduler:
;; ==
;; -- basic block 2 from 37 to 42 -- after reload
;; ==
;;0-->37 [-
--- Comment #4 from ubizjak at gmail dot com 2010-06-09 06:27 ---
(In reply to comment #1)
> It may be broken by revision 160394:
>
> http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00307.html
The add->lea transformation doesn't even trigger in this testcase... You still
have normal add instr
--- Comment #5 from ubizjak at gmail dot com 2010-06-09 07:46 ---
Looking into it.
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
--- Comment #6 from ubizjak at gmail dot com 2010-06-09 12:15 ---
Following patch is also needed to fix conditional splitting (it does not fix
original uncovered problem where BLOCK_FOR_INSN returns null):
Index: i386.md
==
--- Comment #7 from hjl dot tools at gmail dot com 2010-06-09 14:13 ---
(In reply to comment #4)
> (In reply to comment #1)
> > It may be broken by revision 160394:
> >
> > http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00307.html
>
> The add->lea transformation doesn't even trigger in this
--- Comment #8 from hjl dot tools at gmail dot com 2010-06-09 14:16 ---
Whatever we do, we need to preserve Atom add->lea optimization.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
--- Comment #9 from hjl dot tools at gmail dot com 2010-06-09 20:30 ---
(In reply to comment #6)
> Following patch is also needed to fix conditional splitting (it does not fix
> original uncovered problem where BLOCK_FOR_INSN returns null):
>
>
I am not sure this is correct. The code p
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|--- |4.6.0
http://gcc
--- Comment #10 from ubizjak at gmail dot com 2010-06-10 06:18 ---
(In reply to comment #9)
> > Following patch is also needed to fix conditional splitting (it does not fix
> > original uncovered problem where BLOCK_FOR_INSN returns null):
>
> I am not sure this is correct. The code pr
--- Comment #11 from hjl dot tools at gmail dot com 2010-06-10 14:30
---
(In reply to comment #10)
> (In reply to comment #9)
>
> > > Following patch is also needed to fix conditional splitting (it does not
> > > fix
> > > original uncovered problem where BLOCK_FOR_INSN returns null):
--- Comment #12 from ubizjak at gmail dot com 2010-06-10 14:57 ---
(In reply to comment #11)
> > > I am not sure this is correct. The code prior to revision 160394 was
> > > written in such a way to support X86_TUNE_OPT_AGU. We may have missed
> > > some cases. But it is mostly correct
--- Comment #13 from ubizjak at gmail dot com 2010-06-10 14:59 ---
(In reply to comment #12)
> (In reply to comment #11)
>
> > > > I am not sure this is correct. The code prior to revision 160394 was
> > > > written in such a way to support X86_TUNE_OPT_AGU. We may have missed
> > > >
--- Comment #14 from ubizjak at gmail dot com 2010-06-10 15:12 ---
(In reply to comment #11)
> ADD is always faster than LEA for adding a register. However
> there is a special case on Atom where ADD should be avoided.
> It is true that LEA doesn't touch flags and we used it instead
> o
--- Comment #15 from hjl dot tools at gmail dot com 2010-06-10 15:43
---
(In reply to comment #14)
> (In reply to comment #11)
>
> > ADD is always faster than LEA for adding a register. However
> > there is a special case on Atom where ADD should be avoided.
> > It is true that LEA doe
--- Comment #16 from hjl at gcc dot gnu dot org 2010-06-10 16:01 ---
Subject: Bug 44470
Author: hjl
Date: Thu Jun 10 16:00:31 2010
New Revision: 160557
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160557
Log:
Revert the part of r160394 to fix bootstap with --with-arch=atom.
2
--- Comment #17 from hjl dot tools at gmail dot com 2010-06-10 19:16
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|ASSIGNE
28 matches
Mail list logo