C++: Letting compiler know asm block can call function that can throw?

C++: Letting compiler know asm block can call function that can throw?

[Stephan Bergmann]

Hi all,

In LibreOffice's ever-beloved low-level code to synthesize calls to C++ 
virtual functions, I'm having the following problem (on Linux x86_64). 
The function callVirtualMethod at 
<http://cgit.freedesktop.org/libreoffice/core/tree/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx?id=571876c1234ae55aab0198c7e2caf9049fcd230e#n61> 
effectively does the following:

First, call dummy_can_throw_anything that can potentially throw (see 
below for why that's there).  Second, in an asm block, call some virtual 
function (that can potentially throw).  Third, call x86_64::fill_struct 
that can potentially throw (it doesn't, but nobody bothered to annotate 
it as "throw ()").

Now, at least GCC 4.7.0 with -O0 produces a .gcc_except_table section 
for callVirtualMethod, with two call-site table entries each spanning 
the first (dummy_can_throw_anything) and third (x86_64::fill_struct) 
calls, resp., but none spanning the second (asm block) call.  These 
entries are effectively nop, simply calling back into _Unwind_Resume, 
and compiling at higher optimization levels leaves them out anyway 
(leading to callVirtualMethod having no corresponding .gcc_except_table 
section).

The problem is that if the virtual function called through the asm block 
throws an exception, that then immediately leads to std::terminate.  My 
understanding is that because the ip is at the call instruction in the 
asm block that is between the two call-site table entries, the unwind 
machinery thinks this cannot happen and bails out.  (When compiled -O2, 
the code happens to work fine, as there is no .gcc_except_table section 
for this frame at all, so unwinding simply passes through it without 
calling the personality function.)

Making sure that there are no calls to (compiler-visible) functions that 
can throw within callVirtualMethod would happen to make the code also 
work with -O0.  But that would remain a fragile solution.

Is there a way to let the compiler know that the asm block potentially 
calls functions that can throw?  So that it could emit correct code, 
regardless of whether callVirtualMethod happens to have a corresponding 
.gcc_except_table section or not.

(The call to dummy_can_throw_anything, copied from the corresponding 
older code for 32-bit x86, is there for the following reason:  At least 
with some compiler version and some optimization level, on x86 it was 
discovered that the compiler did not emit the .eh_frame data necessary 
for unwinding to successfully pass through this frame at all.  As the 
corresponding x86 code does not have a call to x86_64::fill_struct, the 
compiler apparently considered callVirtualMethod a leaf function and 
optimized accordingly.  The dummy_can_throw_anything hack happened to 
make it do the right thing again, but again this is a fragile solution, 
anyway, that could be replaced with something robust if there were a way 
to annotate the asm block as "calls functions that can throw.")

Stephan

Re: C++: Letting compiler know asm block can call function that can throw?

[Jakub Jelinek]

On Thu, Mar 29, 2012 at 09:05:29AM +0200, Stephan Bergmann wrote:
> In LibreOffice's ever-beloved low-level code to synthesize calls to
> C++ virtual functions, I'm having the following problem (on Linux
> x86_64). The function callVirtualMethod at <http://cgit.freedesktop.org/libreoffice/core/tree/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx?id=571876c1234ae55aab0198c7e2caf9049fcd230e#n61>
> effectively does the following:
> 
> First, call dummy_can_throw_anything that can potentially throw (see
> below for why that's there).  Second, in an asm block, call some
> virtual function (that can potentially throw).  Third, call
> x86_64::fill_struct that can potentially throw (it doesn't, but
> nobody bothered to annotate it as "throw ()").

If the asm isn't in headers, but just in a single short source file
or two, you could try compiling that file with -fnon-call-exceptions.
It is nothing I'd recommend for the whole codebase though.

	Jakub

Re: C++: Letting compiler know asm block can call function that can throw?

[Stephan Bergmann]

On 03/29/2012 09:44 AM, Jakub Jelinek wrote:
> On Thu, Mar 29, 2012 at 09:05:29AM +0200, Stephan Bergmann wrote:
>> In LibreOffice's ever-beloved low-level code to synthesize calls to
>> C++ virtual functions, I'm having the following problem (on Linux
>> x86_64). The function callVirtualMethod at<http://cgit.freedesktop.org/libreoffice/core/tree/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx?id=571876c1234ae55aab0198c7e2caf9049fcd230e#n61>
>> effectively does the following:
>>
>> First, call dummy_can_throw_anything that can potentially throw (see
>> below for why that's there).  Second, in an asm block, call some
>> virtual function (that can potentially throw).  Third, call
>> x86_64::fill_struct that can potentially throw (it doesn't, but
>> nobody bothered to annotate it as "throw ()").
>
> If the asm isn't in headers, but just in a single short source file
> or two, you could try compiling that file with -fnon-call-exceptions.
> It is nothing I'd recommend for the whole codebase though.

Turns out I had to move the callVirtualMethod function containing the 
asm into a source file of its own, anyway.  (Otherwise, even if it no 
longer explicitly called functions that can throw, and thus no longer 
had corresponding .gcc_except_table entries, exception throwing still 
lead to std::terminate.  There are other functions in the same source 
file callVirtualMethod was originally in that do have .gcc_except_table 
entries.  Kind of invalidates my previous explanation of why exception 
handling bailed out to std::terminate.  Looks like I haven't groked it 
yet, anyway.)

So an explicit -fnon-call-exceptions on the command line seems to indeed 
help.  Unfortunately, moving that into a

   #pragma GCC optimize ("non-call-exceptions")

at the top of the source file that defines callVirtualMethod (and 
nothing more) does *not* work.  Is that a bug?

Anyway, would it be worthwhile filing an RFE for an asm annotation 
telling the compiler that it contains code that can throw?

Thanks,
Stephan

Re: C++: Letting compiler know asm block can call function that can throw?

[Richard Guenther]

On Thu, Mar 29, 2012 at 10:47 AM, Stephan Bergmann <sbergman@redhat.com> wrote:
> On 03/29/2012 09:44 AM, Jakub Jelinek wrote:
>>
>> On Thu, Mar 29, 2012 at 09:05:29AM +0200, Stephan Bergmann wrote:
>>>
>>> In LibreOffice's ever-beloved low-level code to synthesize calls to
>>> C++ virtual functions, I'm having the following problem (on Linux
>>> x86_64). The function callVirtualMethod
>>> at<http://cgit.freedesktop.org/libreoffice/core/tree/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx?id=571876c1234ae55aab0198c7e2caf9049fcd230e#n61>
>>> effectively does the following:
>>>
>>> First, call dummy_can_throw_anything that can potentially throw (see
>>> below for why that's there).  Second, in an asm block, call some
>>> virtual function (that can potentially throw).  Third, call
>>> x86_64::fill_struct that can potentially throw (it doesn't, but
>>> nobody bothered to annotate it as "throw ()").
>>
>>
>> If the asm isn't in headers, but just in a single short source file
>> or two, you could try compiling that file with -fnon-call-exceptions.
>> It is nothing I'd recommend for the whole codebase though.
>
>
> Turns out I had to move the callVirtualMethod function containing the asm
> into a source file of its own, anyway.  (Otherwise, even if it no longer
> explicitly called functions that can throw, and thus no longer had
> corresponding .gcc_except_table entries, exception throwing still lead to
> std::terminate.  There are other functions in the same source file
> callVirtualMethod was originally in that do have .gcc_except_table entries.
>  Kind of invalidates my previous explanation of why exception handling
> bailed out to std::terminate.  Looks like I haven't groked it yet, anyway.)
>
> So an explicit -fnon-call-exceptions on the command line seems to indeed
> help.  Unfortunately, moving that into a
>
>  #pragma GCC optimize ("non-call-exceptions")
>
> at the top of the source file that defines callVirtualMethod (and nothing
> more) does *not* work.  Is that a bug?

The optimize pragma has only very limited support for this kind of options,
so yes, it's techincally a bug but don't hold your breath.

> Anyway, would it be worthwhile filing an RFE for an asm annotation telling
> the compiler that it contains code that can throw?

I suppose yes.

Richard.

> Thanks,
> Stephan

Re: C++: Letting compiler know asm block can call function that can throw?

[Stephan Bergmann]

On 03/29/2012 11:16 AM, Richard Guenther wrote:
> On Thu, Mar 29, 2012 at 10:47 AM, Stephan Bergmann<sbergman@redhat.com>  wrote:
>> So an explicit -fnon-call-exceptions on the command line seems to indeed
>> help.  Unfortunately, moving that into a
>>
>>   #pragma GCC optimize ("non-call-exceptions")
>>
>> at the top of the source file that defines callVirtualMethod (and nothing
>> more) does *not* work.  Is that a bug?
>
> The optimize pragma has only very limited support for this kind of options,
> so yes, it's techincally a bug but don't hold your breath.

OK.  (It's just that the way LibreOffice is build, its a PITA to compile 
a single file with differing options...)

>> Anyway, would it be worthwhile filing an RFE for an asm annotation telling
>> the compiler that it contains code that can throw?
>
> I suppose yes.

<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52770> "RFE: Letting 
compiler know asm block can call function that can throw."

Thanks,
Stephan

Re: C++: Letting compiler know asm block can call function that can throw?

[Michael Matz]

Hi,

On Thu, 29 Mar 2012, Stephan Bergmann wrote:

> > > Anyway, would it be worthwhile filing an RFE for an asm annotation 
> > > telling the compiler that it contains code that can throw?
> >
> > I suppose yes.
> 
> <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52770> "RFE: Letting 
> compiler know asm block can call function that can throw."

Actually, with -fnon-call-exceptions volatile asms are already supposed to 
be throwing.  It's just that this got lost with tree-ssa.  With the patch 
and -fnon-call-exceptions a simple "__asm__ volatile (...)" is regarded as 
possibly throwing.

Without -fnon-call-exceptions some parser changes would be required.  How 
about "asm throw (...)" ?


Ciao,
Michael.
Index: tree-eh.c
===================================================================
--- tree-eh.c	(revision 183716)
+++ tree-eh.c	(working copy)
@@ -1959,6 +1959,7 @@ lower_eh_constructs_2 (struct leh_state
       }
       /* FALLTHRU */
 
+    case GIMPLE_ASM:
     case GIMPLE_ASSIGN:
       /* If the stmt can throw use a new temporary for the assignment
          to a LHS.  This makes sure the old value of the LHS is
Index: tree-cfg.c
===================================================================
--- tree-cfg.c	(revision 183716)
+++ tree-cfg.c	(working copy)
@@ -580,6 +580,8 @@ make_edges (void)
 
 	    case GIMPLE_ASM:
 	      make_gimple_asm_edges (bb);
+	      if (is_ctrl_altering_stmt (last))
+		make_eh_edges (last);
 	      fallthru = true;
 	      break;
 

Re: C++: Letting compiler know asm block can call function that can throw?

[Andrew Haley]

On 03/29/2012 02:59 PM, Michael Matz wrote:
> Actually, with -fnon-call-exceptions volatile asms are already supposed to 
> be throwing.  It's just that this got lost with tree-ssa.  With the patch 
> and -fnon-call-exceptions a simple "__asm__ volatile (...)" is regarded as 
> possibly throwing.
> 
> Without -fnon-call-exceptions some parser changes would be required.  How 
> about "asm throw (...)" ?

Is there any point?  I would have thought that -fnon-call-exceptions was
exactly what you need.

Andrew.

Re: C++: Letting compiler know asm block can call function that can throw?

[Stephan Bergmann]

On 03/29/2012 04:12 PM, Andrew Haley wrote:
> On 03/29/2012 02:59 PM, Michael Matz wrote:
>> Actually, with -fnon-call-exceptions volatile asms are already supposed to
>> be throwing.  It's just that this got lost with tree-ssa.  With the patch
>> and -fnon-call-exceptions a simple "__asm__ volatile (...)" is regarded as
>> possibly throwing.
>>
>> Without -fnon-call-exceptions some parser changes would be required.  How
>> about "asm throw (...)" ?
>
> Is there any point?  I would have thought that -fnon-call-exceptions was
> exactly what you need.

But it looks wrong to me to have to mark the complete compilation unit 
for something that should only affect a single asm declaration.  (Also, 
having to specify -fnon-call-exceptions "externally," on the command 
line, is somewhat awkward.)

Stephan

Re: C++: Letting compiler know asm block can call function that can throw?

[Michael Matz]

Hi,

On Thu, 29 Mar 2012, Andrew Haley wrote:

> On 03/29/2012 02:59 PM, Michael Matz wrote:
> > Actually, with -fnon-call-exceptions volatile asms are already supposed to 
> > be throwing.  It's just that this got lost with tree-ssa.  With the patch 
> > and -fnon-call-exceptions a simple "__asm__ volatile (...)" is regarded as 
> > possibly throwing.
> > 
> > Without -fnon-call-exceptions some parser changes would be required.  How 
> > about "asm throw (...)" ?
> 
> Is there any point?  I would have thought that -fnon-call-exceptions was
> exactly what you need.

non-call-exceptions is a relatively big hammer.  It marks _all_ 
non-trivial instructions as throwing.  Providing an explicit marker would 
allow for more granularity.  Granted, the request didn't come often over 
the last years, but it seems like a relatively self-contained and useful 
addition to inline asms.


Ciao,
Michael.

Re: C++: Letting compiler know asm block can call function that can throw?

[Richard Henderson]

On 03/29/2012 03:05 AM, Stephan Bergmann wrote:
> Hi all,
> 
> In LibreOffice's ever-beloved low-level code to synthesize calls to
> C++ virtual functions, I'm having the following problem (on Linux
> x86_64). The function callVirtualMethod at
> <http://cgit.freedesktop.org/libreoffice/core/tree/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx?id=571876c1234ae55aab0198c7e2caf9049fcd230e#n61>
> effectively does the following:

Quoting:

    asm volatile (

        // Fill the xmm registers
        "movq %6, %%rax\n\t"

        "movsd   (%%rax), %%xmm0\n\t"
        "movsd  8(%%rax), %%xmm1\n\t"
        "movsd 16(%%rax), %%xmm2\n\t"
        "movsd 24(%%rax), %%xmm3\n\t"
        "movsd 32(%%rax), %%xmm4\n\t"
        "movsd 40(%%rax), %%xmm5\n\t"
        "movsd 48(%%rax), %%xmm6\n\t"
        "movsd 56(%%rax), %%xmm7\n\t"

        // Fill the general purpose registers
        "movq %5, %%rax\n\t"

        "movq    (%%rax), %%rdi\n\t"
        "movq   8(%%rax), %%rsi\n\t"
        "movq  16(%%rax), %%rdx\n\t"
        "movq  24(%%rax), %%rcx\n\t"
        "movq  32(%%rax), %%r8\n\t"
        "movq  40(%%rax), %%r9\n\t"

        // Perform the call
        "movq %4, %%r11\n\t"
        "movq %7, %%rax\n\t"
        "call *%%r11\n\t"

        // Fill the return values
        "movq   %%rax, %0\n\t"
        "movq   %%rdx, %1\n\t"
        "movsd %%xmm0, %2\n\t"
        "movsd %%xmm1, %3\n\t"
        : "=m" ( rax ), "=m" ( rdx ), "=m" ( xmm0 ), "=m" ( xmm1 )
        : "m" ( pMethod ), "m" ( pGPR ), "m" ( pFPR ), "m" ( nFPR )
        : "rax", "rdi", "rsi", "rdx", "rcx", "r8", "r9", "r11"
    );

Semi-off-topic, I think this asm can be better done with only the
call inside the asm, and the rest handled by the compiler.

  {
    register sal_uInt64 hard_r8 __asm__("rax"); // etc
    register double hard_xmm0 __asm__("xmm0"); // etc

    hard_rdi = pGPR[0]; //etc
    hard_xmm0 = pFPR[0]; //etc
    hard_rax = nFPR;

    asm volatile ("call *%[method]"
                  : "+r"(hard_rax), //etc
                    "+x"(hard_xmm0), //etc
                  : "g" [method] (pMethod)
                  : "memory");

    rax = hard_rax;
    rdx = hard_rdx;
    xmm0 = hard_xmm0;
    xmm1 = hard_xmm1;
  }


Of course, there's still the problem of getting the unwind data correct at
the point of the asm.  I commented about that in the PR you filed.


r~

Re: C++: Letting compiler know asm block can call function that can throw?

[Jan Hubicka]

> On 03/29/2012 03:05 AM, Stephan Bergmann wrote:
> > Hi all,
> > 
> > In LibreOffice's ever-beloved low-level code to synthesize calls to
> > C++ virtual functions, I'm having the following problem (on Linux
> > x86_64). The function callVirtualMethod at
> > <http://cgit.freedesktop.org/libreoffice/core/tree/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx?id=571876c1234ae55aab0198c7e2caf9049fcd230e#n61>
> > effectively does the following:
> 
> Quoting:
> 
>     asm volatile (
> 
>         // Fill the xmm registers
>         "movq %6, %%rax\n\t"
> 
>         "movsd   (%%rax), %%xmm0\n\t"
>         "movsd  8(%%rax), %%xmm1\n\t"
>         "movsd 16(%%rax), %%xmm2\n\t"
>         "movsd 24(%%rax), %%xmm3\n\t"
>         "movsd 32(%%rax), %%xmm4\n\t"
>         "movsd 40(%%rax), %%xmm5\n\t"
>         "movsd 48(%%rax), %%xmm6\n\t"
>         "movsd 56(%%rax), %%xmm7\n\t"
> 
>         // Fill the general purpose registers
>         "movq %5, %%rax\n\t"
> 
>         "movq    (%%rax), %%rdi\n\t"
>         "movq   8(%%rax), %%rsi\n\t"
>         "movq  16(%%rax), %%rdx\n\t"
>         "movq  24(%%rax), %%rcx\n\t"
>         "movq  32(%%rax), %%r8\n\t"
>         "movq  40(%%rax), %%r9\n\t"
> 
>         // Perform the call
>         "movq %4, %%r11\n\t"
>         "movq %7, %%rax\n\t"
>         "call *%%r11\n\t"
> 
>         // Fill the return values
>         "movq   %%rax, %0\n\t"
>         "movq   %%rdx, %1\n\t"
>         "movsd %%xmm0, %2\n\t"
>         "movsd %%xmm1, %3\n\t"
>         : "=m" ( rax ), "=m" ( rdx ), "=m" ( xmm0 ), "=m" ( xmm1 )
>         : "m" ( pMethod ), "m" ( pGPR ), "m" ( pFPR ), "m" ( nFPR )
>         : "rax", "rdi", "rsi", "rdx", "rcx", "r8", "r9", "r11"
>     );
> 
> Semi-off-topic, I think this asm can be better done with only the
> call inside the asm, and the rest handled by the compiler.
> 
>   {
>     register sal_uInt64 hard_r8 __asm__("rax"); // etc
>     register double hard_xmm0 __asm__("xmm0"); // etc
> 
>     hard_rdi = pGPR[0]; //etc
>     hard_xmm0 = pFPR[0]; //etc
>     hard_rax = nFPR;
> 
>     asm volatile ("call *%[method]"
>                   : "+r"(hard_rax), //etc
>                     "+x"(hard_xmm0), //etc
>                   : "g" [method] (pMethod)
>                   : "memory");
> 
>     rax = hard_rax;
>     rdx = hard_rdx;
>     xmm0 = hard_xmm0;
>     xmm1 = hard_xmm1;
>   }
> 
> 
> Of course, there's still the problem of getting the unwind data correct at
> the point of the asm.  I commented about that in the PR you filed.

I think i386 still has the problem that it is small register class target and if you
set rdi/rax and friends as hard registers, you risk reload failures. 
Do we prevent code motion of hard registers sets i.e. at GIMPLE level? (I know pre-reload
scheduler was improved here, but I would not rely on it either).
As soon as hard_rdi/hard_rax set is moved upwards or downwards across memset/division
or other stuff requiring rax or rdx, reload will ICE.

Honza
> 
> 
> r~

Re: C++: Letting compiler know asm block can call function that can throw?

[Richard Henderson]

On 03/29/2012 01:16 PM, Jan Hubicka wrote:
>> Of course, there's still the problem of getting the unwind data correct at
>> the point of the asm.  I commented about that in the PR you filed.
> 
> I think i386 still has the problem that it is small register class target and if you
> set rdi/rax and friends as hard registers, you risk reload failures. 

True, and if this were i386 code I would certainly recommend using the [acd]
constraints instead (for suitible regparm signature).  But this is explicitly
x86_64 code and the compiler has 8 registers otherwise available.

> Do we prevent code motion of hard registers sets i.e. at GIMPLE level?

I don't know for positive, but I'd certainly consider it a bug if we don't.
There are plenty of targets which have no alternative but to use this style
of programming for inline syscalls.


r~

Re: C++: Letting compiler know asm block can call function that can throw?

[Eric Botcazou]

> non-call-exceptions is a relatively big hammer.  It marks _all_
> non-trivial instructions as throwing.

The "all" goes against the "relatively" here, and "relatively" is more correct.
Not all non-trivial instructions are marked as throwing, e.g. loads and stores 
from/to the stack aren't.

-- 
Eric Botcazou

Re: C++: Letting compiler know asm block can call function that can throw?

[Richard Guenther]

On Thu, Mar 29, 2012 at 8:34 PM, Richard Henderson <rth@redhat.com> wrote:
> On 03/29/2012 01:16 PM, Jan Hubicka wrote:
>>> Of course, there's still the problem of getting the unwind data correct at
>>> the point of the asm.  I commented about that in the PR you filed.
>>
>> I think i386 still has the problem that it is small register class target and if you
>> set rdi/rax and friends as hard registers, you risk reload failures.
>
> True, and if this were i386 code I would certainly recommend using the [acd]
> constraints instead (for suitible regparm signature).  But this is explicitly
> x86_64 code and the compiler has 8 registers otherwise available.
>
>> Do we prevent code motion of hard registers sets i.e. at GIMPLE level?

Yes we do (modulo bugs).

> I don't know for positive, but I'd certainly consider it a bug if we don't.
> There are plenty of targets which have no alternative but to use this style
> of programming for inline syscalls.
>
>
> r~

Re: C++: Letting compiler know asm block can call function that can throw?

[Richard Guenther]

On Thu, Mar 29, 2012 at 3:59 PM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Thu, 29 Mar 2012, Stephan Bergmann wrote:
>
>> > > Anyway, would it be worthwhile filing an RFE for an asm annotation
>> > > telling the compiler that it contains code that can throw?
>> >
>> > I suppose yes.
>>
>> <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52770> "RFE: Letting
>> compiler know asm block can call function that can throw."
>
> Actually, with -fnon-call-exceptions volatile asms are already supposed to
> be throwing.  It's just that this got lost with tree-ssa.  With the patch
> and -fnon-call-exceptions a simple "__asm__ volatile (...)" is regarded as
> possibly throwing.
>
> Without -fnon-call-exceptions some parser changes would be required.  How
> about "asm throw (...)" ?
>
>
> Ciao,
> Michael.
> Index: tree-eh.c
> ===================================================================
> --- tree-eh.c   (revision 183716)
> +++ tree-eh.c   (working copy)
> @@ -1959,6 +1959,7 @@ lower_eh_constructs_2 (struct leh_state
>       }
>       /* FALLTHRU */
>
> +    case GIMPLE_ASM:
>     case GIMPLE_ASSIGN:
>       /* If the stmt can throw use a new temporary for the assignment
>          to a LHS.  This makes sure the old value of the LHS is

This does not handle using a temporary for all (register) outputs ...
I suppose the code should walk all SSA defs instead of looking at
the LHS only.

> Index: tree-cfg.c
> ===================================================================
> --- tree-cfg.c  (revision 183716)
> +++ tree-cfg.c  (working copy)
> @@ -580,6 +580,8 @@ make_edges (void)
>
>            case GIMPLE_ASM:
>              make_gimple_asm_edges (bb);
> +             if (is_ctrl_altering_stmt (last))
> +               make_eh_edges (last);
>              fallthru = true;
>              break;

Otherwise this looks reasonable.  With a testcase, I suppose ;)

Richard.

Re: C++: Letting compiler know asm block can call function that can throw?

[Jan Hubicka]

> On Thu, Mar 29, 2012 at 8:34 PM, Richard Henderson <rth@redhat.com> wrote:
> > On 03/29/2012 01:16 PM, Jan Hubicka wrote:
> >>> Of course, there's still the problem of getting the unwind data correct at
> >>> the point of the asm.  I commented about that in the PR you filed.
> >>
> >> I think i386 still has the problem that it is small register class target and if you
> >> set rdi/rax and friends as hard registers, you risk reload failures.
> >
> > True, and if this were i386 code I would certainly recommend using the [acd]
> > constraints instead (for suitible regparm signature).  But this is explicitly
> > x86_64 code and the compiler has 8 registers otherwise available.

Sure, still rdi/rax is the only option for some of instructions, so x86-64
doesn't really solve all the problems.
> >
> >> Do we prevent code motion of hard registers sets i.e. at GIMPLE level?
> 
> Yes we do (modulo bugs).

Good. Note that this also include transformations like frward substitution into
area where hard register is live (i.e. it is not enough to just not touch hard
registers as volatile, but one needs to prevent moving other code in).

Honza
> 
> > I don't know for positive, but I'd certainly consider it a bug if we don't.
> > There are plenty of targets which have no alternative but to use this style
> > of programming for inline syscalls.
> >
> >
> > r~

Re: C++: Letting compiler know asm block can call function that can throw?

[Richard Guenther]

2012/3/30 Jan Hubicka <hubicka@ucw.cz>:
>> On Thu, Mar 29, 2012 at 8:34 PM, Richard Henderson <rth@redhat.com> wrote:
>> > On 03/29/2012 01:16 PM, Jan Hubicka wrote:
>> >>> Of course, there's still the problem of getting the unwind data correct at
>> >>> the point of the asm.  I commented about that in the PR you filed.
>> >>
>> >> I think i386 still has the problem that it is small register class target and if you
>> >> set rdi/rax and friends as hard registers, you risk reload failures.
>> >
>> > True, and if this were i386 code I would certainly recommend using the [acd]
>> > constraints instead (for suitible regparm signature).  But this is explicitly
>> > x86_64 code and the compiler has 8 registers otherwise available.
>
> Sure, still rdi/rax is the only option for some of instructions, so x86-64
> doesn't really solve all the problems.
>> >
>> >> Do we prevent code motion of hard registers sets i.e. at GIMPLE level?
>>
>> Yes we do (modulo bugs).
>
> Good. Note that this also include transformations like frward substitution into
> area where hard register is live (i.e. it is not enough to just not touch hard
> registers as volatile, but one needs to prevent moving other code in).

Motion across hardreg sets/uses are not restricted.  And I would not expect
an optimizing compiler to do that (it's your own fault to use hardregs in
complex C code).

Richard.

Re: C++: Letting compiler know asm block can call function that can throw?

[Jan Hubicka]

> 
> Motion across hardreg sets/uses are not restricted.  And I would not expect
> an optimizing compiler to do that (it's your own fault to use hardregs in
> complex C code).

Well, the syscall sequence is an example of somehting that should be inlined
into arbitrary code w/o potential risk of ICEs.  But I guess if things works in
practice (as they seem), we don't need to worry much at the moment.  Most of
code movement we do is very simple. I don't see how to convince GCC to move
memcpy or division into the middle of a basic block containing the libcall
sequence.... Even when the basic block can be broken up with
-fno-call-exceptions at the asm statement by an EH edge...

Honza
> 
> Richard.

Re: C++: Letting compiler know asm block can call function that can throw?

[Michael Matz]

Hi,

On Fri, 30 Mar 2012, Jan Hubicka wrote:

> > Motion across hardreg sets/uses are not restricted.  And I would not expect
> > an optimizing compiler to do that (it's your own fault to use hardregs in
> > complex C code).
> 
> Well, the syscall sequence is an example of somehting that should be 
> inlined into arbitrary code w/o potential risk of ICEs.

The syscall sequence doesn't consist of multiple independend instructions, 
but rather is one asm with the right constraints.  So gcc has no chance to 
move something between the register setup (which only is explicit after 
reload) and the syscall instruction.  If syscall sequences were 
implemented like this:

inline int syscall1(int number, long arg1) {
  register int ax __asm__("eax");
  register long di __asm__("rdi");
  ax = number;
  di = arg1;
  __asm__ volatile ("syscall");
}

_then_ we would probably get miscompilations here and there.


Ciao,
Michael.

Re: C++: Letting compiler know asm block can call function that can throw?

[Jakub Jelinek]

On Mon, Apr 02, 2012 at 04:07:59PM +0200, Michael Matz wrote:
> On Fri, 30 Mar 2012, Jan Hubicka wrote:
> 
> > > Motion across hardreg sets/uses are not restricted.  And I would not expect
> > > an optimizing compiler to do that (it's your own fault to use hardregs in
> > > complex C code).
> > 
> > Well, the syscall sequence is an example of somehting that should be 
> > inlined into arbitrary code w/o potential risk of ICEs.
> 
> The syscall sequence doesn't consist of multiple independend instructions, 
> but rather is one asm with the right constraints.  So gcc has no chance to 
> move something between the register setup (which only is explicit after 
> reload) and the syscall instruction.  If syscall sequences were 
> implemented like this:
> 
> inline int syscall1(int number, long arg1) {
>   register int ax __asm__("eax");
>   register long di __asm__("rdi");
>   ax = number;
>   di = arg1;
>   __asm__ volatile ("syscall");
> }
> 
> _then_ we would probably get miscompilations here and there.

That is actually what is used on most targets, including x86_64 (i?86 is an
exception here, because it has single hard register constraints for most of
the interesting registers).

	Jakub

Re: C++: Letting compiler know asm block can call function that can throw?

[Michael Matz]

Hi,

On Mon, 2 Apr 2012, Jakub Jelinek wrote:

> > inline int syscall1(int number, long arg1) {
> >   register int ax __asm__("eax");
> >   register long di __asm__("rdi");
> >   ax = number;
> >   di = arg1;
> >   __asm__ volatile ("syscall");
> > }
> > 
> > _then_ we would probably get miscompilations here and there.
> 
> That is actually what is used on most targets, including x86_64

Yikes!  That's indeed the case.  I'll want to retract what I said, concede 
with Honza that we're lucky and add that we're lucky mostly because 
register variables are not regarded as gimple registers, hence all stores 
to such variables are regarded as VDEFs.  So there will be VDEF/VUSE 
chains between initializer and syscall, which prevents most code motion 
into that chain.  That itself doesn't e.g. prevent the load/store 
disambiguator from disambiguating two such decls, even if they refer to 
the same hardreg.  So we really are merely lucky, with enough effort we 
probably could create a "miscompiling" testcase.


Ciao,
Michael.

Re: C++: Letting compiler know asm block can call function that can throw?

[Hans-Peter Nilsson]

On Mon, 2 Apr 2012, Michael Matz wrote:
> On Mon, 2 Apr 2012, Jakub Jelinek wrote:
>
> > > inline int syscall1(int number, long arg1) {
> > >   register int ax __asm__("eax");
> > >   register long di __asm__("rdi");
> > >   ax = number;
> > >   di = arg1;
> > >   __asm__ volatile ("syscall");
> > > }
> > >
> > > _then_ we would probably get miscompilations here and there.
> >
> > That is actually what is used on most targets, including x86_64
>
> Yikes!  That's indeed the case.  I'll want to retract what I said, concede
> with Honza that we're lucky and add that we're lucky mostly because
> register variables are not regarded as gimple registers, hence all stores
> to such variables are regarded as VDEFs.  So there will be VDEF/VUSE
> chains between initializer and syscall, which prevents most code motion
> into that chain.  That itself doesn't e.g. prevent the load/store
> disambiguator from disambiguating two such decls, even if they refer to
> the same hardreg.  So we really are merely lucky, with enough effort we
> probably could create a "miscompiling" testcase.

Lucky perhaps, but documented lucky: this is documented (grep
sysint extend.texi) to work, to avoid having talented gcc
hackers saying "oh, that worked?  You have to _stop doing that_;
you've just been lucky in previous versions" rather that "oops,
looks like I broke that; I'll fix it post-haste".

(There's *one* test-case in gcc.target/cris/asmreg-1.c; this
could certainly do with more coverage.)

brgds, H-P