[Bug c/59615] New: "asm goto" output or at least clobbered operands

[Bug c/59615] New: "asm goto" output or at least clobbered operands

[hpa at zytor dot com]

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

            Bug ID: 59615
           Summary: "asm goto" output or at least clobbered operands
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hpa at zytor dot com

There are a number of uses of "asm goto" which requires at least on dyadic
architectures like x86 the ability to clobber an operand.  However, the current
definition of "asm goto" doesn't allow any output operands, and the clobber
list only works on specific registers (which are generally not allowed to be
inputs, anyway.)

For example:

    asm goto("add %1,%0 ; "
         "jc %l[t_err] ; "
         "cmp %2,%0 ; "
             "ja %l[t_err] ; "
         : "+r" (addr)
                 : "g" (size), "g" (limit)
         : : t_err);
    return false;
t_err:
    return true;

This is part of a proposed implementation of access_ok(), a limit test with a
guard for wraparound, used heavily in the Linux kernel.  There needs to be a
way to communicate to gcc that "addr" is clobbered by the first instruction.

[Bug c/59615] "asm goto" output or at least clobbered operands

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The reason for the limitation is that any needed reload out can't be then
inserted after the asm goto, but all the other edges would need to be split and
the reload outs inserted on all the edges.

Looking at your example though, can you explain why you want to use asm goto
then?  I'd say that for addition, two conditional jumps and one comparison you
definitely don't want to use asm goto, the compiler can't see through it thus
can't optimize it.  Why isn't what GCC generates sufficient?  Do you have a
testcase?

[Bug c/59615] "asm goto" output or at least clobbered operands

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
Looking at the assembly, you probably want:

--cut here--
int test (int a, int b, int c)
{
  unsigned r = a + b;

  if (r < (unsigned) a)
    return 1;
  else if (r > c)
    return 1;

  return 0;
}
--cut here--

gcc-4.8.2 -O2:

test:
        addl    %esi, %edi
        movl    $1, %eax
        jc      .L2
        xorl    %eax, %eax
        cmpl    %edx, %edi
        seta    %al
.L2:
        rep ret

Please note how the compiler is able to generate jc without compare insn.
>From gcc-bugs-return-438636-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Dec 28 10:38:30 2013
Return-Path: <gcc-bugs-return-438636-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8421 invoked by alias); 28 Dec 2013 10:38:30 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 8385 invoked by uid 48); 28 Dec 2013 10:38:26 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/59615] "asm goto" output or at least clobbered operands
Date: Sat, 28 Dec 2013 10:38:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59615-4-GDpj5JkGtR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59615-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59615-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-12/txt/msg02291.txt.bz2
Content-length: 263

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

--- Comment #3 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Uroš Bizjak from comment #2)

>   if (r < (unsigned) a)

Explicit cast is not needed here, the compiler will do it for you.
>From gcc-bugs-return-438637-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Dec 28 10:39:21 2013
Return-Path: <gcc-bugs-return-438637-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9184 invoked by alias); 28 Dec 2013 10:39:21 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9155 invoked by uid 48); 28 Dec 2013 10:39:17 -0000
From: "tkoenig at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/59604] Constant comparisons with -fno-range-check and int(z'...')
Date: Sat, 28 Dec 2013 10:39:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tkoenig at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: tkoenig at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on assigned_to everconfirmed
Message-ID: <bug-59604-4-Vj0qPXgwjt@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59604-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59604-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-12/txt/msg02292.txt.bz2
Content-length: 573

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY604

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2013-12-28
           Assignee|unassigned at gcc dot gnu.org      |tkoenig at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #6 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
I have a patch.

[Bug c/59615] "asm goto" output or at least clobbered operands

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
But it would warn about it with -Wsign-compare.  You want unsigned r =
(unsigned) a + b; or similar to avoid undefined behavior if there is a
possibility of signed integer overflow.  Anyway, you definitely don't want to
use inline asm in this case, if there is some code GCC doesn't optimize as good
as you'd like to, just report that.

[Bug c/59615] "asm goto" output or at least clobbered operands

[hpa at zytor dot com]

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

--- Comment #5 from H. Peter Anvin <hpa at zytor dot com> ---
Please don't get hung up on the specific example; I just picked one that was
small and self-contained.

The biggest reason we can't use gcc's native bits in the kernel are items where
we have to use the kernel's "alternative" feature, where the code is
dynamically patched.

[Bug c/59615] "asm goto" output or at least clobbered operands

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #4)
> Anyway, you definitely don't want
> to use inline asm in this case, if there is some code GCC doesn't optimize
> as good as you'd like to, just report that.

One common similar case where people are tempted to use asm goto with an output
operand is, on x86: compute a*b and check if it overflowed. x86 has flags for
that but AFAIR they are not modeled in the .md files. (I was also interested in
output operands for asm goto in PR52381, but there is no good example there)

[Bug c/59615] "asm goto" output or at least clobbered operands

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #6)
> (In reply to Jakub Jelinek from comment #4)
> > Anyway, you definitely don't want
> > to use inline asm in this case, if there is some code GCC doesn't optimize
> > as good as you'd like to, just report that.
> 
> One common similar case where people are tempted to use asm goto with an
> output operand is, on x86: compute a*b and check if it overflowed. x86 has
> flags for that but AFAIR they are not modeled in the .md files. (I was also
> interested in output operands for asm goto in PR52381, but there is no good
> example there)

They are modelled in the .md files now, we just don't have general purpose
builtins for this yet in GCC 4.9, it is only used for -fsanitize=undefined
right now.

[Bug c/59615] "asm goto" output or at least clobbered operands

[glisse at gcc dot gnu.org]

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

--- Comment #8 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #7)
> They are modelled in the .md files now, we just don't have general purpose
> builtins for this yet in GCC 4.9, it is only used for -fsanitize=undefined
> right now.

Ah, right, I thought you had only added an expander, nice that it is properly
modeled now (thanks), though I am yet to find C code where combine (or other)
ends up matching this pattern, which seems doable without a builtin. (well, we
are still losing the high half of the product if we use that pattern, but
that's less often needed)

Sorry for the hijack, back to comment 5 as the real motivation.

[Bug inline-asm/59615] "asm goto" output or at least clobbered operands

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
   Target Milestone|---                         |11.0
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed in GCC 11 with r11-5002.