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.
