[Bug jit/87291] Add support for inline asm to libgccjit

[Bug jit/87291] Add support for inline asm to libgccjit

[bouanto at zoho dot com]

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

bouanto at zoho dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bouanto at zoho dot com

--- Comment #2 from bouanto at zoho dot com ---
I'd like to have inline asm support as well.
I would see an API like this:

For global asm:
gcc_jit_context_add_module_asm(gcc_jit_context* ctxt, gcc_jit_location* loc,
const char* asm)

For local (in function) asm:
gcc_jit_function* gcc_jit_block_add_inline_asm(gcc_jit_block* block,
gcc_jit_location* loc, gcc_jit_type* return_type, int num_params,
gcc_jit_params** params, const char* asm, const char* constraints, bool
has_side_effects, bool align_stack, enum gcc_jit_asm_dialect dialect)

This will return a function that can then be called as usual with
gcc_jit_context_new_call. The return type of the function can either be void, a
single value or a struct depending on the constraints.
In my case I would need the asm dialects Intel and ATT.

Maybe has_side_effects and align_stack could be rvalues: I'm not sure.

Thanks.

[Bug jit/87291] Add support for inline asm to libgccjit

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Note to self: GCC's documentation for using asm from C:
  https://gcc.gnu.org/onlinedocs/gcc/Using-Assembly-Language-with-C.html

Thanks for the suggestions.

I'm not seeing how the proposed entrypoints in comment #2 would work; sorry.

I suspect we'd need to closely mirror the "basic" and "extended" asm approaches
from C linked to above (probably using the terms "basic" and "extended" in the
entrypoint names, to signal to the developer that that's what the calls would
be analogous to).

I'm wary about basic asm at the top level (outside functions), given that
libgccjit has such an unusual relationship with the rest of the compiler (it
might work, but it might have unexpected snags).

I think the extended asm would need be along the lines of
   gcc_jit_block_add_extended_asm (gcc_jit_block *block,
                                   ...something...);

possibly with and without goto labels.

Do you have a specific use-case in mind?  Thanks

[Bug jit/87291] Add support for inline asm to libgccjit

[bouanto at zoho dot com]

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

--- Comment #4 from bouanto at zoho dot com ---
Oh, maybe it wasn't clear, but what I meant by constraints is: the output
operands, the input operands, and clobbers.

I guess we could make multiple parameters in the function for those.
For the things like (old) in "=r" (old), those would simply be sent as
arguments to the returned function.

So, an example like this:

```c
bool old;
__asm__ ("btsl %2,%1\n\t" // Turn on zero-based bit #Offset in Base.
         "sbb %0,%0"      // Use the CF to calculate old.
   : "=r" (old), "+rm" (*Base)
   : "Ir" (Offset)
   : "cc");
```

would be created like this:

```c
gcc_jit_field *field_old = gcc_jit_context_new_field(ctxt, NULL, bool_type,
"old");
gcc_jit_field *field_base = …
gcc_jit_field *fields[2] = {field_bool, field_base};
gcc_jit_struct *return_type = gcc_jit_context_new_struct_type (ctxt, NULL,
"return_type", 2, fields);
gcc_jit_type *param_type = …
gcc_jit_param *param = gcc_jit_context_new_param(ctxt, NULL, param_type,
"param_offset")
bool is_volatile = false;
bool align_stack = false; // Does gcc have this option?
enum gcc_jit_asm_dialect dialect = GCC_JIT_ASM_DIALECT_INTEL;
gcc_jit_function* function = gcc_jit_block_add_extended_asm(block, NULL,
return_type, 1, &param,
    "btsl %2,%1\n\t"
    "sbb %0,%0", "=r,+rm" /* for "=r" and "+rm", it's comma-separated */, "Ir",
"cc", is_volatile, align_stack, dialect);
gcc_jit_context_new_call(ctxt, function, NULL, 1, &offset_rvalue); // This
returns the struct whose type was defined earlier.
```

[Bug jit/87291] Add support for inline asm to libgccjit

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to bouanto from comment #4)
> So, an example like this:
> 
> ```c
> bool old;
> __asm__ ("btsl %2,%1\n\t" // Turn on zero-based bit #Offset in Base.
>          "sbb %0,%0"      // Use the CF to calculate old.
>    : "=r" (old), "+rm" (*Base)
>    : "Ir" (Offset)
>    : "cc");

Could we instead try to get this produced from normal gimple/C code?

[Bug jit/87291] Add support for inline asm to libgccjit

[bouanto at zoho dot com]

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

--- Comment #6 from bouanto at zoho dot com ---
(In reply to Andrew Pinski from comment #5)
> (In reply to bouanto from comment #4)
> > So, an example like this:
> > 
> > ```c
> > bool old;
> > __asm__ ("btsl %2,%1\n\t" // Turn on zero-based bit #Offset in Base.
> >          "sbb %0,%0"      // Use the CF to calculate old.
> >    : "=r" (old), "+rm" (*Base)
> >    : "Ir" (Offset)
> >    : "cc");
> 
> Could we instead try to get this produced from normal gimple/C code?

I'm not sure I understand what you mean here? Does what you suggest change the
API in any way?

[Bug jit/87291] Add support for inline asm to libgccjit

[dmalcolm at gcc dot gnu.org]

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

--- Comment #7 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #5)
> (In reply to bouanto from comment #4)
> > So, an example like this:
> > 
> > ```c
> > bool old;
> > __asm__ ("btsl %2,%1\n\t" // Turn on zero-based bit #Offset in Base.
> >          "sbb %0,%0"      // Use the CF to calculate old.
> >    : "=r" (old), "+rm" (*Base)
> >    : "Ir" (Offset)
> >    : "cc");
> 
> Could we instead try to get this produced from normal gimple/C code?

Note that this is the example from "6.47.2.3 Output Operands" on
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
I believe bouanto is merely citing it as an example.

[Bug jit/87291] Add support for inline asm to libgccjit

[dmalcolm at gcc dot gnu.org]

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

--- Comment #8 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Reading the docs for extended asm, I think the API entrypoint would need to
look something like:

extern void
gcc_jit_block_add_extended_asm (gcc_jit_block *block,
                                int is_volatile,
                                int is_inline,
                                const char *asm_template,
                                int num_output_operands,
                                gcc_jit_asm_operand **output_operands,
                                int num_input_operands,
                                gcc_jit_asm_operand **input_operands,
                                int num_clobbers,
                                const char **clobbers,
                                int num_goto_labels,
                                gcc_jit_block **goto_labels);

which is a lot of arguments, and we'd also need a way to create
gcc_jit_asm_operand instances.

If there are goto_labels, then the asm is implicitly "goto"-qualified; the asm
also is treated as potentially falling through to whatever is after it in the
block; it doesn't terminated its gcc_jit_block.

[Bug jit/87291] Add support for inline asm to libgccjit

[bouanto at zoho dot com]

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

--- Comment #9 from bouanto at zoho dot com ---
Ok, so you would go without a function-like API.

I think you're missing a few parameters here, like the ASM dialect (intel vs
ATT) unless that would be the string ".intel_syntax;" at the start of the
asm_template. Also, the parameter location might be missing.

Does gcc provide a way to specify whether the stack should be aligned properly,
or is it done automatically, or should it be specified manually in asm_template
with a string like ".align 32"?

(In reply to David Malcolm from comment #8)
> Reading the docs for extended asm, I think the API entrypoint would need to
> look something like:
> 
> extern void
> gcc_jit_block_add_extended_asm (gcc_jit_block *block,
> 			        int is_volatile,
> 			        int is_inline,
>                                 const char *asm_template,
> 				int num_output_operands,
> 				gcc_jit_asm_operand **output_operands,
> 				int num_input_operands,
> 				gcc_jit_asm_operand **input_operands,
> 				int num_clobbers,
> 				const char **clobbers,
> 				int num_goto_labels,
> 				gcc_jit_block **goto_labels);
> 
> which is a lot of arguments, and we'd also need a way to create
> gcc_jit_asm_operand instances.
> 
> If there are goto_labels, then the asm is implicitly "goto"-qualified; the
> asm also is treated as potentially falling through to whatever is after it
> in the block; it doesn't terminated its gcc_jit_block.

[Bug jit/87291] Add support for inline asm to libgccjit

[programmerjake at gmail dot com]

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

programmerjake at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |programmerjake at gmail dot com

--- Comment #10 from programmerjake at gmail dot com ---
(In reply to bouanto from comment #9)
> Does gcc provide a way to specify whether the stack should be aligned
> properly, or is it done automatically, or should it be specified manually in
> asm_template with a string like ".align 32"?

using ".align 32" in the assembly string would align the machine code instead
of the stack, so that's probably not what you want.

>From what I understand, gcc doesn't currently provide a way to align the stack
for inline assembly even in C.

[Bug jit/87291] Add support for inline asm to libgccjit

[programmerjake at gmail dot com]

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

--- Comment #11 from programmerjake at gmail dot com ---
(In reply to programmerjake from comment #10)
> (In reply to bouanto from comment #9)
> > Does gcc provide a way to specify whether the stack should be aligned
> > properly, or is it done automatically, or should it be specified manually in
> > asm_template with a string like ".align 32"?
> 
> using ".align 32" in the assembly string would align the machine code
> instead of the stack, so that's probably not what you want.
> 
> From what I understand, gcc doesn't currently provide a way to align the
> stack for inline assembly even in C.

However, I think it would be a good idea to have a parameter/flag set aside for
supporting aligning the stack for when GCC gains support for that, the flag can
just cause an error for now.

[Bug jit/87291] Add support for inline asm to libgccjit

[bouanto at zoho dot com]

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

--- Comment #12 from bouanto at zoho dot com ---
Since there would be many options, we could use a bitflags parameter instead of
having multiple parameters for the options.

[Bug jit/87291] Add support for inline asm to libgccjit

[dmalcolm at gcc dot gnu.org]

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

--- Comment #13 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
An alternative approach that reduces the number of params by splitting it into
successive calls:

extern gcc_jit_extended_asm *
gcc_jit_block_add_extended_asm (gcc_jit_block *block,
                                int is_volatile,
                                int is_inline,
                                const char *asm_template);
                                // location?
gcc_jit_extended_asm_add_output_operand (gcc_jit_extended_asm *ext_asm,
                                         ...something...);
gcc_jit_extended_asm_add_input_operand (gcc_jit_extended_asm *ext_asm,
                                        ...something...);
gcc_jit_extended_asm_add_clobber (gcc_jit_extended_asm *ext_asm,
                                  const char *victim);
gcc_jit_extended_asm_add_goto_label (gcc_jit_extended_asm *ext_asm,
                                     gcc_jit_block *block);

[Bug jit/87291] Add support for inline asm to libgccjit

[dmalcolm at gcc dot gnu.org]

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

--- Comment #14 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Or even move the flags to API calls:

extern gcc_jit_extended_asm *
gcc_jit_block_add_extended_asm (gcc_jit_block *block,
                                const char *asm_template);
                                // location?
extern void
gcc_jit_extended_asm_set_volatile_flag (gcc_jit_extended_asm *ext_asm,
                                        int flag);
extern void
gcc_jit_extended_asm_set_inline_flag (gcc_jit_extended_asm *ext_asm,
                                      int flag);

[Bug jit/87291] Add support for inline asm to libgccjit

[bouanto at zoho dot com]

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

--- Comment #15 from bouanto at zoho dot com ---
(In reply to David Malcolm from comment #14)
> Or even move the flags to API calls:
> 
> extern gcc_jit_extended_asm *
> gcc_jit_block_add_extended_asm (gcc_jit_block *block,
>                                 const char *asm_template);
> 				// location?
> extern void
> gcc_jit_extended_asm_set_volatile_flag (gcc_jit_extended_asm *ext_asm,
>                                         int flag);
> extern void
> gcc_jit_extended_asm_set_inline_flag (gcc_jit_extended_asm *ext_asm,
>                                       int flag);

I'm okay with either way.

For top-level assembly, I guess we can have a similar function, but without the
parameters that would not be needed.

[Bug jit/87291] Add support for inline asm to libgccjit

[dmalcolm at gcc dot gnu.org]

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

--- Comment #16 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Created attachment 48677
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48677&action=edit
Work-in-progress patch

I had a go at implementing this; attached is a work-in-progress prototype.

It works for simple cases (albeit with various TODO/FIXME items).

See the test case at the end of the patch for two examples of usage.

How does it look?

Various issues that occurred to me while prototyping this:

"gotos"/labels/control flow
================================
The new entrypoint "gcc_jit_block_add_extended_asm" in the patch assumes no
control flow, and libgccjit enforces a requirement that gcc_jit_blocks are
terminated.

If there are to be conditional jumps, then I think we need a 2nd entrypoint
"gcc_jit_block_end_with_asm" or somesuch that takes an array of gcc_jit_blocks
and terminates the gcc_jit_block.  Rather than having a jump vs implicitly
falling through, you'd have to specify both destination blocks.

"Basic" asm
================
Do we actually need "basic" asm (as opposed to extended asm)?
In particular I'm wary about asm code that's outside of any given function.  Is
that needed?

asm dialects
============
I'm ignoring this in the prototype.  I would prefer not to expose
dialect-selection as a first-class entrypoint in the libgccjit API as it
touches the interaction with the driver, and libgccjit uses the driver code in
a weird way compared with the rest of GCC.  Perhaps you'd be able to affect it
via e.g. gcc_jit_context_add_driver_option.

[Bug jit/87291] Add support for inline asm to libgccjit

[dmalcolm at gcc dot gnu.org]

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

--- Comment #17 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(also uploaded to
https://dmalcolm.fedorapeople.org/gcc/2020-06-04/0001-FIXME-WIP-on-extended-asm-support.patch
)

[Bug jit/87291] Add support for inline asm to libgccjit

[bouanto at zoho dot com]

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

--- Comment #18 from bouanto at zoho dot com ---
See answers below.

(In reply to David Malcolm from comment #16)
> Created attachment 48677 [details]
> Work-in-progress patch
> 
> I had a go at implementing this; attached is a work-in-progress prototype.
> 
> It works for simple cases (albeit with various TODO/FIXME items).
> 
> See the test case at the end of the patch for two examples of usage.
> 
> How does it look?

This API looks good.

> 
> Various issues that occurred to me while prototyping this:
> 
> "gotos"/labels/control flow
> ================================
> The new entrypoint "gcc_jit_block_add_extended_asm" in the patch assumes no
> control flow, and libgccjit enforces a requirement that gcc_jit_blocks are
> terminated.
> 
> If there are to be conditional jumps, then I think we need a 2nd entrypoint
> "gcc_jit_block_end_with_asm" or somesuch that takes an array of
> gcc_jit_blocks and terminates the gcc_jit_block.  Rather than having a jump
> vs implicitly falling through, you'd have to specify both destination blocks.

I'm fine with this gcc_jit_block_end_with_asm function, but does a compiler
usually need that? I'm not sure it's needed. How would a compiler know what are
the jumps from the inline asm? (Maybe I don't understand what's going on in
this case.)

> 
> "Basic" asm
> ================
> Do we actually need "basic" asm (as opposed to extended asm)?
> In particular I'm wary about asm code that's outside of any given function. 
> Is that needed?

That's something I use in my compiler, so that would be very appreciated if you
could add this.

> 
> asm dialects
> ============
> I'm ignoring this in the prototype.  I would prefer not to expose
> dialect-selection as a first-class entrypoint in the libgccjit API as it
> touches the interaction with the driver, and libgccjit uses the driver code
> in a weird way compared with the rest of GCC.  Perhaps you'd be able to
> affect it via e.g. gcc_jit_context_add_driver_option.

It seems in inline assembly in gcc supports starting the template with
".intel_syntax;" to set the intel dialect. Would that work in this case?

Thanks for your work.

[Bug jit/87291] Add support for inline asm to libgccjit

[dmalcolm at gcc dot gnu.org]

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

--- Comment #19 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to bouanto from comment #18)
> (In reply to David Malcolm from comment #16)
> > Created attachment 48677 [details]
> This API looks good.

Thanks.

[...snip...]

> > "Basic" asm
> > ================
> > Do we actually need "basic" asm (as opposed to extended asm)?
> > In particular I'm wary about asm code that's outside of any given function. 
> > Is that needed?
> 
> That's something I use in my compiler, so that would be very appreciated if
> you could add this.

Can you give concrete example(s) please?  I'm having trouble thinking through
how this would work.

[...snip...]

[Bug jit/87291] Add support for inline asm to libgccjit

[bouanto at zoho dot com]

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

--- Comment #20 from bouanto at zoho dot com ---
Well, there's syntax for assembly at the top-level so the user can enter
anything he wants, like in C.
I can craft you an example if you need to, though.

(In reply to David Malcolm from comment #19)
> (In reply to bouanto from comment #18)
> > (In reply to David Malcolm from comment #16)
> > > Created attachment 48677 [details]
> > This API looks good.
> 
> Thanks.
> 
> [...snip...]
> 
> > > "Basic" asm
> > > ================
> > > Do we actually need "basic" asm (as opposed to extended asm)?
> > > In particular I'm wary about asm code that's outside of any given function. 
> > > Is that needed?
> > 
> > That's something I use in my compiler, so that would be very appreciated if
> > you could add this.
> 
> Can you give concrete example(s) please?  I'm having trouble thinking
> through how this would work.
> 
> [...snip...]

[Bug jit/87291] Add support for inline asm to libgccjit

[dmalcolm at gcc dot gnu.org]

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

--- Comment #21 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to bouanto from comment #20)
> Well, there's syntax for assembly at the top-level so the user can enter
> anything he wants, like in C.
> I can craft you an example if you need to, though.

I could use a concrete example of what you might use in C.

An issue is ordering: in C, these top-level statements presumably are ordered
relative to each other and the function bodies, based on the order they're seen
by the parser (though I'm guessing here).  Would something similar happen based
on the order of calls to gcc_jit_context_new_function?

[Bug jit/87291] Add support for inline asm to libgccjit

[dmalcolm at gcc dot gnu.org]

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

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #48677|0                           |1
        is obsolete|                            |

--- Comment #22 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Created attachment 48684
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48684&action=edit
Updated work-in-progress patch which adds "asm goto" support

Here's an updated version of the patch which adds "asm goto" support.  grep for
test_i386_basic_asm_3a to see an example.

Also uploaded to:
https://dmalcolm.fedorapeople.org/gcc/2020-06-05/0001-FIXME-WIP-on-extended-asm-support-v2.patch

Does this API make sense?

[Bug jit/87291] Add support for inline asm to libgccjit

[bouanto at zoho dot com]

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

--- Comment #23 from bouanto at zoho dot com ---
Created attachment 48685
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48685&action=edit
Example of global assembly

See answers below.

(In reply to David Malcolm from comment #22)
> Created attachment 48684 [details]
> Updated work-in-progress patch which adds "asm goto" support
> 
> Here's an updated version of the patch which adds "asm goto" support.  grep
> for test_i386_basic_asm_3a to see an example.
> 
> Also uploaded to:
> https://dmalcolm.fedorapeople.org/gcc/2020-06-05/0001-FIXME-WIP-on-extended-
> asm-support-v2.patch
> 
> Does this API make sense?

Yes, now I understand what you meant.
The API looks good.


> I could use a concrete example of what you might use in C.

> An issue is ordering: in C, these top-level statements presumably are ordered
> relative to each other and the function bodies, based on the order they're seen 
> by the parser (though I'm guessing here).  Would something similar happen based 
> on the order of calls to gcc_jit_context_new_function?

I attached an example of global assembly.

I don't understand the ordering issue.
I also don't understand how gcc_jit_context_new_function is used here.

[Bug jit/87291] Add support for inline asm to libgccjit

[dmalcolm at gcc dot gnu.org]

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

--- Comment #24 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to bouanto from comment #23)
> Created attachment 48685 [details]
> Example of global assembly

[...snip....; thanks for the feedback]

> I attached an example of global assembly.

Thanks.

> I don't understand the ordering issue.
> I also don't understand how gcc_jit_context_new_function is used here.

I see that you have a balanced .pushsection/.popsection pair in your example. 
Is it ever the case that people might want to have a .pushsection, then some C 
code, then a .popsection?  (and, by analogy, the same for libgccjit rather than
C).  That's the ordering issue I'm concerned about, since at that point it
matters what order the hand-written asm is in relative to the
compiler-generated asm.

[Bug jit/87291] Add support for inline asm to libgccjit

[bouanto at zoho dot com]

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

--- Comment #25 from bouanto at zoho dot com ---
(In reply to David Malcolm from comment #24)
> (In reply to bouanto from comment #23)
> > Created attachment 48685 [details]
> > Example of global assembly
> 
> [...snip....; thanks for the feedback]
> 
> > I attached an example of global assembly.
> 
> Thanks.
> 
> > I don't understand the ordering issue.
> > I also don't understand how gcc_jit_context_new_function is used here.
> 
> I see that you have a balanced .pushsection/.popsection pair in your
> example.  Is it ever the case that people might want to have a .pushsection,
> then some C  code, then a .popsection?  (and, by analogy, the same for
> libgccjit rather than C).  That's the ordering issue I'm concerned about,
> since at that point it matters what order the hand-written asm is in
> relative to the compiler-generated asm.

I think we can assume that people won't try to mix top-level assembly and C
code.
So, we can assume the order won't matter and document this behavior.

[Bug jit/87291] Add support for inline asm to libgccjit

[dmalcolm at gcc dot gnu.org]

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

--- Comment #26 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(there's also -fno-toplevel-reorder which makes me wonder if we do need to
preserve ordering with such constructs)

[Bug jit/87291] Add support for inline asm to libgccjit

[dmalcolm at gcc dot gnu.org]

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

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #48684|0                           |1
        is obsolete|                            |

--- Comment #27 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Created attachment 48694
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48694&action=edit
v3 of the work-in-progress patch

Here's an updated version of the patch; also uploaded to:
https://dmalcolm.fedorapeople.org/gcc/2020-06-06/0001-FIXME-WIP-on-extended-asm-support-v3.patch

In particular, this adds a new:
  gcc_jit_context_add_top_level_asm
entrypoint.  On implementing this, it hooks into the symbol table like the C
frontend does, so it looks like it will respect ordering as much as the C
frontend does.

How does this look?  The top-level asm code is barely tested though; I'd
appreciate a way to verify it from the automated test case.

Changes in v3:
* added gcc_jit_context_add_top_level_asm
* drop redundant gcc_jit_extended_asm_add_goto_label
* added gcc_jit_extended_asm_as_object
* started adding documentation
* added comments to libgccjit.h
* consolidated test-asm.c, grouping create/verify pairs
* add test coverage for "volatile"
* initial implementation of make_debug_string
* added some error-checking

[Bug jit/87291] Add support for inline asm to libgccjit

[dmalcolm at gcc dot gnu.org]

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

--- Comment #28 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Generated HTML for docs (albeit without css) here:
https://dmalcolm.fedorapeople.org/gcc/2020-06-06/asm-v3.html

[Bug jit/87291] Add support for inline asm to libgccjit

[bouanto at zoho dot com]

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

--- Comment #29 from bouanto at zoho dot com ---
This API looks fine.

Another test would be to create a simple function, the equivalent of this:

#include <assert.h>

asm(
    "add:\n"
    "movq %rdi, %rax\n"
    "add %rsi, %rax\n"
    "ret\n");

extern int add(int, int);

int main(void) {
    assert(add(40, 2) == 42);
}

(In reply to David Malcolm from comment #27)
> Created attachment 48694 [details]
> v3 of the work-in-progress patch
> 
> Here's an updated version of the patch; also uploaded to:
> https://dmalcolm.fedorapeople.org/gcc/2020-06-06/0001-FIXME-WIP-on-extended-
> asm-support-v3.patch
> 
> In particular, this adds a new:
>   gcc_jit_context_add_top_level_asm
> entrypoint.  On implementing this, it hooks into the symbol table like the C
> frontend does, so it looks like it will respect ordering as much as the C
> frontend does.
> 
> How does this look?  The top-level asm code is barely tested though; I'd
> appreciate a way to verify it from the automated test case.
> 
> Changes in v3:
> * added gcc_jit_context_add_top_level_asm
> * drop redundant gcc_jit_extended_asm_add_goto_label
> * added gcc_jit_extended_asm_as_object
> * started adding documentation
> * added comments to libgccjit.h
> * consolidated test-asm.c, grouping create/verify pairs
> * add test coverage for "volatile"
> * initial implementation of make_debug_string
> * added some error-checking

[Bug jit/87291] Add support for inline asm to libgccjit

[dmalcolm at gcc dot gnu.org]

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

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-06-08
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED

--- Comment #30 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to Antoni from comment #29)
> asm(
>     "add:\n"
>     "movq %rdi, %rax\n"
>     "add %rsi, %rax\n"
>     "ret\n");

Thanks; I've updated the testcases and examples to use this.  I needed to
slightly tweak this to allow the dynamic linker to find it, to allow
gcc_jit_result_get_code to work.

[Bug jit/87291] Add support for inline asm to libgccjit

[dmalcolm at gcc dot gnu.org]

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

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #48694|0                           |1
        is obsolete|                            |

--- Comment #31 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Created attachment 48704
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48704&action=edit
v4 of the patch

v4 patch, close to being finished (I hope)

Also uploaded to:
 
https://dmalcolm.fedorapeople.org/gcc/2020-06-08/0001-FIXME-WIP-on-extended-asm-support-v4.patch

C API docs:
 
https://dmalcolm.fedorapeople.org/gcc/2020-06-08/jit-html-docs/topics/asm.html
C++ API docs:
 
https://dmalcolm.fedorapeople.org/gcc/2020-06-08/jit-html-docs/cp/topics/asm.html

[Bug jit/87291] Add support for inline asm to libgccjit

[bouanto at zoho dot com]

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

--- Comment #32 from Antoni <bouanto at zoho dot com> ---
Thanks; that looks really nice.

The function gcc_jit_context_add_top_level_asm might be missing a location
parameter.


(In reply to David Malcolm from comment #31)
> Created attachment 48704 [details]
> v4 of the patch
> 
> v4 patch, close to being finished (I hope)
> 
> Also uploaded to:
>  
> https://dmalcolm.fedorapeople.org/gcc/2020-06-08/0001-FIXME-WIP-on-extended-
> asm-support-v4.patch
> 
> C API docs:
>  
> https://dmalcolm.fedorapeople.org/gcc/2020-06-08/jit-html-docs/topics/asm.
> html
> C++ API docs:
>  
> https://dmalcolm.fedorapeople.org/gcc/2020-06-08/jit-html-docs/cp/topics/asm.
> html

[Bug jit/87291] Add support for inline asm to libgccjit

[dmalcolm at gcc dot gnu.org]

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

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

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

--- Comment #33 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Patch pushed to master for gcc 11: g:421d0d0f54294a7bf2872b3b2ac521ce0fa9869e
(this bug didn't get notified for some reason).

Changes since v4:
* added location to gcc_jit_context_add_top_level_asm
* more logging
* filter testsuite to x86 targets
* use LIBGCCJIT_ABI_15 and #ifdef LIBGCCJIT_HAVE_ASM_STATEMENTS
* fix asm_operand::make_debug_string
* fixes to write_reproducer
* update expected debug-string results to reflect escaping fixes from
g:fec573408310139e1ffc42741fbe46b4f2947592
* fixed missing comments

Marking this one as resolved.