[Bug inline-asm/56148] New: [4.8 Regression] inline asm matching constraint with different mode

[Bug inline-asm/56148] New: [4.8 Regression] inline asm matching constraint with different mode

[jakub at gcc dot gnu.org]

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

             Bug #: 56148
           Summary: [4.8 Regression] inline asm matching constraint with
                    different mode
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: inline-asm
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jakub@gcc.gnu.org


void
foo (void)
{
  unsigned char e[16];
  unsigned long a, b, c, d;
  __asm__ __volatile__ ("" : "=d" (a), "=&c" (c), "=&D" (d), "=&a" (b)
               : "0" (-1U), "mr" (e), "1" (128 >> 5), "2" (e), "3" (-1U));
}

is rejected since LRA merge on x86_64-linux at -O2:
rh905862.i: In function ‘foo’:
rh905862.i:6:3: error: ‘asm’ operand has impossible constraints
   __asm__ __volatile__ ("" : "=d" (a), "=&c" (c), "=&D" (d), "=&a" (b)
   ^

The testcase is questionable, because a, c and b are DImode, while -1U, 128 >>
5
and -1U are all SImode using 0/1/3 constraints matching those DImodes.
But we accept it with reload or with -O0 even with LRA.

[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode

[jakub at gcc dot gnu.org]

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

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

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

[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode

[sergio at serjux dot com]

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

Sérgio Basto <sergio at serjux dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sergio at serjux dot com

--- Comment #1 from Sérgio Basto <sergio at serjux dot com> 2013-02-04 03:06:45 UTC ---
hi, 
This happens when compile VirtualBox-4.2.6 with gcc-4.8

the code of in question is include/iprt/asm.h line 4167

[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode

[sergio at serjux dot com]

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

--- Comment #2 from Sérgio Basto <sergio at serjux dot com> 2013-02-04 03:12:35 UTC ---
Hi again, 
this is not a duplicated bug of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55512 ?

[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-04 07:02:05 UTC ---
Of course not, the other PR was an ICE (and got fixed already months ago), this
one is rejection of (questionable) code, the compiler doesn't crash on it and
it is still present on the turnk.

[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode

[sergio at serjux dot com]

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

--- Comment #4 from Sérgio Basto <sergio at serjux dot com> 2013-02-04 19:46:55 UTC ---
Created attachment 29351
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29351
the questionable code

hi, send in attach the code , (that in think) that is in discussion. To see if
we can fix it , to avoid this compile error  .

[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
           Priority|P3                          |P1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-02-08
     Ever Confirmed|0                           |1

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-08 15:19:58 UTC ---
I suppose the user might expect that the frontend magically extends to
the matching operands width ...

I suppose valid as we accepted it before.  Confirmed.

[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode

[steven at gcc dot gnu.org]

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

--- Comment #6 from Steven Bosscher <steven at gcc dot gnu.org> 2013-02-12 00:14:47 UTC ---
In gcc 4.7.2, reload resolved this with a pair of moves.

>From the .197r.ira and 198r.reload dumps, with the asm_operands
split out and the insns before the asm condensed, for readability:

.197r.ira_gcc472 (.208r.ira_gcc480 is identical except for insn uids):
(insn 5 (set (reg:SI 67) (const_int -1)))
(insn 6 (set (reg/f:DI 68) // and clobber flags, irrelevant
            (plus:DI (reg/f:DI 20 frame) (const_int -16)))
(insn 17 6 18 2 (set (reg:DI 65 [ d ]) (reg/f:DI 68)))  
(insn 18 (set (reg:SI 69) (const_int 4)))  // 128>>5
(insn 10 18 0 2 (parallel [
            (set (reg:DI 63 [ a ])
                (asm_operands/v:DI ("") ("=d") 0 ...))
            (set (reg:DI 64 [ c ])
                (asm_operands/v:DI ("") ("=&c") 1 ...))
            (set (reg:DI 65 [ d ])
                (asm_operands/v:DI ("") ("=&D") 2 ...))
            (set (reg:DI 66 [ b ])
                (asm_operands/v:DI ("") ("=&a") 3 ...))
            (clobber (reg:QI 18 fpsr))
            (clobber (reg:QI 17 flags))
        ]) t.c:6 -1)

asm output operands:
                    [   
                        (reg:SI 67)
                        (reg:DI 65 [ d ])
                        (reg:SI 69)
                        (reg:DI 65 [ d ])
                        (reg:SI 67)
                    ]
asm input operands: 
                    [   
                        (asm_input:SI ("0") (null):0)
                        (asm_input:DI ("mr") (null):0)
                        (asm_input:SI ("1") (null):0)
                        (asm_input:DI ("2") (null):0)
                        (asm_input:SI ("3") (null):0)
                    ]


.198r.reload_gcc472 (no gcc480 equivalent due to ICE):
(insn 5 (set (reg:SI 0 ax [67]) (const_int -1)))             
(insn 17 (set (reg:DI 5 di [orig:65 d] [65])
        (plus:DI (reg/f:DI 7 sp) (const_int -24))))
(insn 18 (set (reg:SI 2 cx [69]) (const_int 4)))
(insn 21 (set (reg:SI 1 dx) (reg:SI 0 ax [67]))) // reload
(insn 22 (set (reg:DI 4 si) (reg:DI 5 di [orig:65 d] [65]))) // reload
(insn 10 22 19 2 (parallel [
            (set (reg:DI 1 dx [orig:63 a] [63])
                (asm_operands/v:DI ("") ("=d") 0 ...))
            (set (reg:DI 2 cx [orig:64 c] [64])
                (asm_operands/v:DI ("") ("=&c") 1 ...))
            (set (reg:DI 5 di [orig:65 d] [65])
                (asm_operands/v:DI ("") ("=&D") 2 ...))
            (set (reg:DI 0 ax [orig:66 b] [66])
                (asm_operands/v:DI ("") ("=&a") 3 ...))
            (clobber (reg:QI 18 fpsr))
            (clobber (reg:QI 17 flags))
        ]) t.c:6 -1)

asm output operands:
                    [
                        (reg:SI 1 dx)
                        (reg:DI 4 si)
                        (reg:SI 2 cx [69])
                        (reg:DI 5 di [orig:65 d ] [65])
                        (reg:SI 0 ax [67])
                    ]
asm input operands: 
                    [
                        (asm_input:SI ("0") (null):0)
                        (asm_input:DI ("mr") (null):0)
                        (asm_input:SI ("1") (null):0)
                        (asm_input:DI ("2") (null):0)
                        (asm_input:SI ("3") (null):0)
                    ]



LRA tries a *lot* more than just two moves:

Creates new registers:
         Choosing alt 0 in insn 10:  (0) =d  (1) =&c  (2) =&D  (3) =&a  (4) 0 
(5) mr  (6) 1  (7) 2  (8) 3
      Creating newreg=73 from oldreg=63, assigning class DREG to r73
      Creating newreg=74 from oldreg=65, assigning class DIREG to r74
      Creating newreg=75 from oldreg=66, assigning class AREG to r75
   10:
{r73:DI=asm_operands;r64:DI=asm_operands;r74:DI=asm_operands;r75:DI=asm_operands;clobber
fpsr:QI;clobber flags:QI;}
      REG_DEAD r69:SI
      REG_DEAD r67:SI
      REG_UNUSED r66:DI
      REG_UNUSED r65:DI
      REG_UNUSED r64:DI
      REG_UNUSED r63:DI
      REG_UNUSED fpsr:QI
      REG_UNUSED flags:QI
    Inserting insn reload before:
   20: clobber r73:DI
   21: r73:DI#0=r67:SI
   22: r74:DI=r65:DI
   23: clobber r75:DI
   24: r75:DI#0=r67:SI

The sets to the subregs of r73 and r75 are the loads of -1U which
is in r67:SI as per insn 5.

The first two of the new registers could be the same moves that reload
attempts to make, but it's difficult to tell because of the slim RTL
dumps. GDB will tell... In any case, if r64 is created for the second
move from reload (insn 22), then LRA is trying DIREG for it while reload
uses SIREG.



Next LRA tries and fails with some inheritance attempts:
         Assigning to 73 (cl=DREG, orig=63, freq=3000, tfirst=73,
tfreq=3000)...
           Assign 1 to reload r73 (freq=3000)
         Assigning to 75 (cl=AREG, orig=66, freq=3000, tfirst=75,
tfreq=3000)...
         Trying 0: spill 67(freq=3000)   Now best 0(cost=-1000)

      Spill r67(hr=0, freq=3000) for r75
           Assign 0 to reload r75 (freq=3000)
         Assigning to 74 (cl=DIREG, orig=65, freq=2000, tfirst=74,
tfreq=2000)...
         Trying 5: spill 65(freq=3000)   Now best 5(cost=1000)

      Spill r65(hr=5, freq=3000) for r74
           Assign 5 to reload r74 (freq=2000)
         Assigning to 72 (cl=GENERAL_REGS, orig=72, freq=2000, tfirst=72,
tfreq=2000)...
           Assign 5 to reload r72 (freq=2000)
  Reassigning non-reload pseudos
           Assign 4 to r65 (freq=3000)
           Assign 37 to r67 (freq=3000)

Creates some more new registers for the previous new registers:
         Choosing alt 0 in insn 10:  (0) =d  (1) =&c  (2) =&D  (3) =&a  (4) 0 
(5) mr  (6) 1  (7) 2  (8) 3
      Creating newreg=76 from oldreg=74, assigning class DIREG to r76
      Creating newreg=77 from oldreg=75, assigning class AREG to r77
   10:
{r73:DI=asm_operands;r64:DI=asm_operands;r76:DI=asm_operands;r77:DI=asm_operands;clobber
fpsr:QI;clobber flags:QI;}
      REG_UNUSED r74:DI
      REG_UNUSED r73:DI
      REG_UNUSED r75:DI
      REG_DEAD r65:DI
      REG_DEAD r69:SI
      REG_UNUSED r64:DI
    Inserting insn reload before:
   25: r76:DI=r74:DI
   26: clobber r77:DI
   27: r77:DI#0=r75:DI#0

Tries and fails again with some inheritance attempts, and gives up:
         Assigning to 77 (cl=AREG, orig=66, freq=3000, tfirst=77,
tfreq=3000)...
         Assigning to 76 (cl=DIREG, orig=65, freq=2000, tfirst=76,
tfreq=2000)...
           Assign 5 to reload r76 (freq=2000)
  2nd iter for reload pseudo assignments:
         Reload r77 assignment failure
          Spill reload r75(hr=0, freq=3000)
          Spill reload r73(hr=1, freq=3000)
          Spill reload r76(hr=5, freq=2000)
         Assigning to 73 (cl=DREG, orig=63, freq=3000, tfirst=73,
tfreq=3000)...
           Assign 1 to reload r73 (freq=3000)
         Assigning to 75 (cl=AREG, orig=66, freq=3000, tfirst=75,
tfreq=3000)...
           Assign 0 to reload r75 (freq=3000)
         Assigning to 77 (cl=AREG, orig=66, freq=3000, tfirst=77,
tfreq=3000)...
         Assigning to 76 (cl=DIREG, orig=65, freq=2000, tfirst=76,
tfreq=2000)...
           Assign 5 to reload r76 (freq=2000)
           Assign 0 to reload r77 (freq=3000)
deleting insn with uid = 10.

[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode

[steven at gcc dot gnu.org]

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

Steven Bosscher <steven at gcc dot gnu.org> changed:

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

--- Comment #7 from Steven Bosscher <steven at gcc dot gnu.org> 2013-02-12 16:24:39 UTC ---
(in my previous post I of course mean inputs and constraints...)

Breaking down the insn once more in something that's more readable
to me at least:

(parallel [
   (set (reg:DI 63 [ a ]) (asm_in[0] (reg:SI 67) "0"))
   (set (reg:DI 64 [ c ]) (asm_in[1] (reg:DI 65) "mr"))
   (set (reg:DI 65 [ d ]) (asm_in[2] (reg:SI 69) "1"))
   (set (reg:DI 66 [ b ]) (asm_in[3] (reg:DI 65) "2"))
                          (asm_in[4] (reg:SI 67) "3")])

so
- r67:SI must match r63:DI
- r69:SI must match r64:DI
- r65:DI must match r65:DI
- r67:SI must match r66:DI

The last constraint comes from CSE, which transforms:

[   (reg:SI 67)
    (reg:DI 68)
    (reg:SI 69)
    (reg:DI 70)
    (reg:SI 71) ]

to

[   (reg:SI 67)
    (reg/f:DI 68)
    (reg:SI 69)
    (reg/f:DI 68)
    (reg:SI 67) ]

because r70 and r68 have the same value before CSE:

    6: {r68:DI=frame:DI-0x10;clobber flags:CC;}
    8: {r70:DI=frame:DI-0x10;clobber flags:CC;}

and CSE cleans that up:

    6: {r68:DI=frame:DI-0x10;clobber flags:CC;}
    8: r70:DI=r68:DI

Disabling or undoing that transformation makes the ICE disappear.
This is also in effect what old reload does with reload insn 21.

[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode

[vmakarov at gcc dot gnu.org]

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

--- Comment #8 from Vladimir Makarov <vmakarov at gcc dot gnu.org> 2013-02-12 17:44:56 UTC ---
Author: vmakarov
Date: Tue Feb 12 17:44:47 2013
New Revision: 195988

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195988
Log:
2013-02-12  Vladimir Makarov  <vmakarov@redhat.com>

    PR inline-asm/56148
    * lra-constraints.c (process_alt_operands): Match early clobber
    operand with itself.  Check conflicts with earlyclobner only if
    the operand is not reloaded.  Prefer to reload conflicting operand
    if earlyclobber and matching operands are the same.

2013-02-12  Vladimir Makarov  <vmakarov@redhat.com>

    PR inline-asm/56148
    * gcc.target/i386/pr56148.c: New test.


Added:
    trunk/gcc/testsuite/gcc.target/i386/pr56148.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lra-constraints.c
    trunk/gcc/testsuite/ChangeLog

[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode

[steven at gcc dot gnu.org]

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

Steven Bosscher <steven at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #9 from Steven Bosscher <steven at gcc dot gnu.org> 2013-02-12 18:09:22 UTC ---
Grrr, I'm still merely trying to understand this problem, and Vlad
has already committed a fix...  :-)

[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode

[steven at gcc dot gnu.org]

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

--- Comment #10 from Steven Bosscher <steven at gcc dot gnu.org> 2013-02-12 18:12:00 UTC ---
Vlad, could you please explain a bit how you figured out this issue
so quickly? (I mean, apart from experience, of course.)

[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode

[sergio at serjux dot com]

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

--- Comment #11 from Sérgio Basto <sergio at serjux dot com> 2013-02-12 18:38:06 UTC ---
Vlad, don't wanna rush you , but let me know when we have this patch on gcc of
Fedora rawhide , to continue testing compilation of VirtualBox .
Thanks,

[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode

[vmakarov at redhat dot com]

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

Vladimir Makarov <vmakarov at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at redhat dot com

--- Comment #12 from Vladimir Makarov <vmakarov at redhat dot com> 2013-02-12 18:52:05 UTC ---
(In reply to comment #10)
> Vlad, could you please explain a bit how you figured out this issue
> so quickly? (I mean, apart from experience, of course.)

Actually I worked on this for 2.5 days.  The patch affects very sensitive LRA
code.  I think there is very small probability that the patch affects other
targets (so I am going to do a merge trunk into lra branch at the end of week).

The problem was in using the same pseudo for two input operands only one of
which is matching the same pseudo which is an earlyclobber.

[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode

[sergio at serjux dot com]

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

--- Comment #13 from Sérgio Basto <sergio at serjux dot com> 2013-02-21 17:45:53 UTC ---
Hi, it see that was applied on gcc-4.8.0-0.12 

Thanks,

[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode

[fm3 at os dot inf.tu-dresden.de]

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

Frank Mehnert <fm3 at os dot inf.tu-dresden.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fm3 at os dot
                   |                            |inf.tu-dresden.de

--- Comment #14 from Frank Mehnert <fm3 at os dot inf.tu-dresden.de> 2013-02-22 14:39:44 UTC ---
(In reply to comment #0)
> void
> foo (void)
> {
>   unsigned char e[16];
>   unsigned long a, b, c, d;
>   __asm__ __volatile__ ("" : "=d" (a), "=&c" (c), "=&D" (d), "=&a" (b)
>                : "0" (-1U), "mr" (e), "1" (128 >> 5), "2" (e), "3" (-1U));
> }
> 
> is rejected since LRA merge on x86_64-linux at -O2:
> rh905862.i: In function ‘foo’:
> rh905862.i:6:3: error: ‘asm’ operand has impossible constraints
>    __asm__ __volatile__ ("" : "=d" (a), "=&c" (c), "=&D" (d), "=&a" (b)
>    ^
> 
> The testcase is questionable, because a, c and b are DImode, while -1U, 128 >>
> 5
> and -1U are all SImode using 0/1/3 constraints matching those DImodes.
> But we accept it with reload or with -O0 even with LRA.

Glad that gcc-4.8 does now behave as before but I would also like to understand
what is questionable about this testcase. How to improve it?

[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode

[vmakarov at gcc dot gnu.org]

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

--- Comment #15 from Vladimir Makarov <vmakarov at gcc dot gnu.org> 2013-02-22 16:30:33 UTC ---
Author: vmakarov
Date: Fri Feb 22 16:30:22 2013
New Revision: 196223

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196223
Log:
2013-02-22  Vladimir Makarov  <vmakarov@redhat.com>

    PR inline-asm/56148
    * lra-constraints.c (process_alt_operands): Reload operand
    conflicting with earlier clobber only if no more other conflicting
    operands.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lra-constraints.c