[Bug rtl-optimization/19398] secondary reloads don't consider "m" alternatives

[Bug rtl-optimization/19398] secondary reloads don't consider "m" alternatives

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19398

Uros Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ra
             Target|i686-*-*                    |
           Priority|P2                          |P3
   Last reconfirmed|2006-10-22 21:37:38         |2012-10-27 21:37:38
      Known to fail|                            |4.8.0

--- Comment #12 from Uros Bizjak <ubizjak at gmail dot com> 2012-10-27 08:14:02 UTC ---
LRA still doesn't consider "m" alternatives:

test:
        movss   %xmm0, -4(%rsp)
        flds    -4(%rsp)
        fmul    %st(0), %st
        fstps   -4(%rsp)
(*)     movss   -4(%rsp), %xmm1
(*)     cvttss2si       %xmm1, %eax
        ret

[Bug rtl-optimization/19398] secondary reloads don't consider "m" alternatives

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19398

Uros Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at gcc dot gnu.org

--- Comment #13 from Uros Bizjak <ubizjak at gmail dot com> 2012-11-13 18:33:55 UTC ---
CC LRA masters.

[Bug rtl-optimization/19398] secondary reloads don't consider "m" alternatives

[uros at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19398

--- Comment #14 from uros at gcc dot gnu.org 2012-11-20 18:02:49 UTC ---
Author: uros
Date: Tue Nov 20 18:02:36 2012
New Revision: 193671

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193671
Log:
2012-11-20  Uros Bizjak  <ubizjak@gmail.com>

    * config/i386/i386.md (fix_trunc<MODEF:mode><SWI48:mode>_sse): Macroize
    insn from fix_trunc<mode>{si,di}_sse using SWI48 mode iterator.
    (peephole2 to avoid vector decoded forms): Macroize peephole2
    using MODEF mode iterator.  Use SWI48 mode iterator instead of SWI48x.

2012-11-20  Uros Bizjak  <ubizjak@gmail.com>

    PR target/19398
    * config/i386/i386.md
    (peephole2 to shorten x87->SSE reload sequences): Remove peephole2.
    * config/i386/i386.h (enum ix86_tune_indices)
    <IX86_TUNE_SHORTEN_X87_SSE>: Remove.
    * config/i386/i386.h (initial_ix86_tune_features): Update.

2012-11-20  Vladimir Makarov  <vmakarov@redhat.com>

    PR target/19398
    * lra-constraints.c (process_alt_operands): Discourage reloads
    through secodnary memory.

testsuite/ChangeLog:

2012-11-20  Uros Bizjak  <ubizjak@gmail.com>

    PR target/19398
    * gcc.target/i386/pr19398.c: New test.


Added:
    trunk/gcc/testsuite/gcc.target/i386/pr19398.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
    trunk/gcc/config/i386/i386.h
    trunk/gcc/config/i386/i386.md
    trunk/gcc/lra-constraints.c
    trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/19398] secondary reloads don't consider "m" alternatives

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19398

Uros Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                URL|                            |http://gcc.gnu.org/ml/gcc-p
                   |                            |atches/2012-11/msg01693.htm
                   |                            |l
         Resolution|                            |FIXED
   Target Milestone|---                         |4.8.0
      Known to fail|4.8.0                       |

--- Comment #15 from Uros Bizjak <ubizjak at gmail dot com> 2012-11-20 18:28:43 UTC ---
Implemented in 4.8.0.

[Bug rtl-optimization/19398] secondary reloads don't consider "m" alternatives

[uros at gcc dot gnu dot org]

------- Comment #11 from uros at gcc dot gnu dot org  2006-10-21 19:27 -------
Subject: Bug 19398

Author: uros
Date: Sat Oct 21 19:27:02 2006
New Revision: 117935

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117935
Log:
        PR target/19398
        * config/i386/i386.md (fix_trunc?f?i_sse): Add peephole2
        patterns to use memory input operand in x87->mem->XMM
        reload sequences.  Skip transformation for TARGET_K8.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.md


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19398

[Bug rtl-optimization/19398] secondary reloads don't consider "m" alternatives

[bonzini at gcc dot gnu dot org]

------- Additional Comments From bonzini at gcc dot gnu dot org  2005-08-08 10:17 -------
... though this would not help PR17236, of course.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19398

[Bug rtl-optimization/19398] secondary reloads don't consider "m" alternatives

[bonzini at gcc dot gnu dot org]

------- Additional Comments From bonzini at gcc dot gnu dot org  2005-08-08 09:58 -------
The solution may as well be to make -mfpmath=sse good enough, that it can be
enabled by default when -msse -msse2 is used...

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19398

[Bug rtl-optimization/19398] secondary reloads don't consider "m" alternatives

[dalej at gcc dot gnu dot org]

------- Additional Comments From dalej at gcc dot gnu dot org  2005-08-01 18:46 -------
This is very close to the problem I ran into reported here:
http://gcc.gnu.org/ml/gcc/2005-07/msg01084.html
That one is fixed by the combination of the patch in PR 19653 and the patch here:
http://gcc.gnu.org/ml/gcc/2005-07/msg01123.html
However that is insufficient to fix this case.  The difficulty is that regmove causes the same pseudo to 
be used for the operands and the result of the multiply.  Consider that reg as all one, ST(0) is the best 
place for it, and you get the extra move.  If you turn off regmove, the patches above fix this problem.
Maybe we should do that?  It seems like the register allocator should be doing what regmove is trying 
to do.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19398

[Bug rtl-optimization/19398] secondary reloads don't consider "m" alternatives

[uros at kss-loka dot si]

------- Additional Comments From uros at kss-loka dot si  2005-03-15 12:34 -------
(In reply to comment #6)
> But a peephole solution would fix a single backend, whilst I assume any kind of 

Also, every insn pattern that accepts memory input would need an appropriate
peephole2 pattern...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19398

[Bug rtl-optimization/19398] secondary reloads don't consider "m" alternatives

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-15 12:23 -------
But a peephole solution would fix a single backend, whilst I assume any kind of 
reload fix could improve code generation with multiple backends at the same 
time.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19398

[Bug rtl-optimization/19398] secondary reloads don't consider "m" alternatives

[bernds_cb1 at t-online dot de]

------- Additional Comments From bernds_cb1 at t-online dot de  2005-03-15 11:44 -------
Interesting problem.  I was temporarily confused by rth's mention of secondary
reloads; it's actually secondary memory that we allocate here.  What happens is

1. Notice none of the alternatives fit as-is
2. Decide that we'd like to use the first alternative (accepting "x")
3. Push a reload to move from a register in class "f" to a reloadreg in "x"
4. Notice that we need secondary memory for that
5. Fail to notice that we could just use that secondary memory location in the
insn's other alternative.

Not sure yet how best to fix it.  Unlike some other problems with reload, I
think peepholes can take care of this without leaving anything unnecessary behind.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19398

[Bug rtl-optimization/19398] secondary reloads don't consider "m" alternatives

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2005-03-15 10:10 -------
CC'ing reload guru

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernds_cb1 at t-online dot
                   |                            |de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19398

[Bug rtl-optimization/19398] secondary reloads don't consider "m" alternatives

[uros at kss-loka dot si]

------- Additional Comments From uros at kss-loka dot si  2005-01-18 12:22 -------
The solution with peepholes is here:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01473.html

However, it was suggested that fixing reload is a better approach.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19398

[Bug rtl-optimization/19398] secondary reloads don't consider "m" alternatives

[rth at gcc dot gnu dot org]

------- Additional Comments From rth at gcc dot gnu dot org  2005-01-18 11:20 -------
This doesn't really have anything to do with sse.  We have a value in "f" and
decide it should be in "x", and discount the "m" alternative.  Could be fixed
by having reload look at "m" when considering secondary reloads.

It's sure to be mildly complicated by wanting to not keep the value in memory
if it could be inherited by multiple instructions, but it's definitely a win
for x86 code density to avoid explicit loads when the value is otherwise unused.

The only target solution I can think of is peepholes.  But we could easily need
Quite A Lot of them in the x86 port, so I don't think this an ideal solution.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |rtl-optimization
           Keywords|ssemmx                      |
            Summary|Non-optimal code with       |secondary reloads don't
                   |cvttss2si                   |consider "m" alternatives


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19398