[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.