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.
