[Bug target/39723] [4.5/4.6 Regression][cond-optab] worse code with long long shifts on v850

[Bug target/39723] [4.5/4.6 Regression][cond-optab] worse code with long long shifts on v850

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.2                       |4.5.3

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-12-16 13:03:03 UTC ---
GCC 4.5.2 is being released, adjusting target milestone.

[Bug target/39723] [4.5/4.6/4.7 Regression][cond-optab] worse code with long long shifts on v850

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.3                       |4.5.4

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-04-28 14:51:19 UTC ---
GCC 4.5.3 is being released, adjusting target milestone.

[Bug target/39723] [4.6/4.7/4.8 Regression][cond-optab] worse code with long long shifts on v850

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.4                       |4.6.4

[Bug target/39723] [4.7/4.8/4.9 Regression][cond-optab] worse code with long long shifts on v850

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.4                       |4.7.4

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-04-12 15:15:43 UTC ---
GCC 4.6.4 has been released and the branch has been closed.

[Bug target/39723] [4.7/4.8/4.9/4.10 Regression][cond-optab] worse code with long long shifts on v850

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39723

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.4                       |4.8.4

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
The 4.7 branch is being closed, moving target milestone to 4.8.4.

[Bug target/39723] [4.8/4.9/5 Regression][cond-optab] worse code with long long shifts on v850

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39723

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.4                       |4.8.5

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.4 has been released.

[Bug target/39723] [4.8/4.9/5 Regression][cond-optab] worse code with long long shifts on v850

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39723

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com
           Assignee|unassigned at gcc dot gnu.org      |vmakarov at redhat dot com

--- Comment #8 from Jeffrey A. Law <law at redhat dot com> ---
Vlad, this looks like a register allocation issue to me.

Using the current trunk configured for v850-elf, compiling the testcase from
c#0 with -O2 and comparing it to the pre-cond-optab merge, I see that we're not
coalescing some of the allocnos as aggressively as perhaps we should.

Let's start with a13 and a17 and work backwards from their hard register
assignments:



      Popping a13(r46,l0)  -- assign reg 12
      Popping a17(r53,l0)  -- assign reg 10



These registers are related by a "copy" if we look up a bit in the .ira dump:

      Forming thread by copy 0:a13r46-a17r53 (freq=125):
        Result (freq=7000): a13r46(5000) a17r53(2000)

  cp0:a13(r46)<->a17(r53)@125:shuffle

Looking at the conflicts:

;; a13(r46,l0) conflicts: a1(r68,l0) a0(r69,l0) a2(r70,l0) a4(r42,l0)
a5(r67,l0) a6(r66,l0) a14(r62,l0) a15(r61,l0) a16(r60,l0)
;;     total conflict hard regs:
;;     conflict hard regs:

;; a17(r53,l0) conflicts: a2(r70,l0) a4(r42,l0) a5(r67,l0) a6(r66,l0)
;;     total conflict hard regs:
;;     conflict hard regs:

Failing to allocate these two registers to r10 results in a 3-operand add (2
bytes longer) and an unnecessary move (2 bytes).  Fixing that would appear to
eliminate the regression.

For reference, the add insn is defined as:

(define_insn "addsi3"
  [(set (match_operand:SI 0 "register_operand" "=r,r,r")
        (plus:SI (match_operand:SI 1 "register_operand" "%0,r,r")
                 (match_operand:SI 2 "nonmemory_operand" "rJ,K,U")))
   (clobber (reg:CC CC_REGNUM))]

Alternative 0 is preferred whenever possible as it allows us to generate the
shorter add instruction.

I'd appreciate if you could investigate when you have the opportunity.

[Bug target/39723] [4.8/4.9/5 Regression][cond-optab] worse code with long long shifts on v850

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39723

Vladimir Makarov <vmakarov at gcc dot gnu.org> changed:

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

--- Comment #9 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #8)

Thanks for the investigation, Jeff.  Coalescing in IRA is done by register cost
propagation.  Unfortunately, p46 gets a hard register (12) first, then p53 is
processed and it gets reg 10 as p53 occurs in insn 14 involving reg 10.

  12: r10:SI=call [r70:SI] argc:0
      REG_CALL_DECL `random'
   14: {r53:SI=r10:SI&0xf;clobber psw:CC;}
      REG_DEAD r10:SI
      REG_UNUSED psw:CC

IRA has a propagation cost algorithm from pseudos (through chains of pseudos). 
This approach was observed as working better than different explicit coalescing
algorithms, especially when we have irregular register files and when we are
using dynamic register classes in IRA.  

The propagation algorithm takes conflicting pseudos costs (preferences) into
account too.  So it is pretty good algorithm.  Unfortunately, there is no
analogous mechanism for hard registers.  If IRA had it, it would propagate
preference of p53 (reg 10) to p46 before assigning a hard reg to p46.

  I am not sure that the PR will be fixed for GCC-5.0 but it would be a good
small project for RA to consider in future.

  Interesting that if p53 were processed first for assigning, we would not have
such problem.

[Bug target/39723] [4.8/4.9/5 Regression][cond-optab] worse code with long long shifts on v850

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39723

--- Comment #10 from Jeffrey A. Law <law at redhat dot com> ---
Yea, as is the case with coloring algorithms order of popping off the coloring
stack will impact the final allocation in either a positive or negative way. 
I'm not at all worried about those kind of effects.

Adding the hard register costing propagating stuff would probably help. Given
that register based calling conventions as well as the oddities in the x86 ISA
that there's a ton of hard register costing information we could exploit.

I'm certainly far less concerned with this specific BZ, but I think it
highlights a minor generic improvement that might be made to IRA.  Your call
if/when/how to attack.

[Bug target/39723] [4.8/4.9/5/6 Regression][cond-optab] worse code with long long shifts on v850

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39723

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.5                       |4.9.3

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.

[Bug target/39723] [4.9/5/6 Regression][cond-optab] worse code with long long shifts on v850

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39723

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.

[Bug target/39723] [4.9/5/6 Regression][cond-optab] worse code with long long shifts on v850

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39723

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4