Hi Robin, Richard,
> But we do know all possible intrinsics, statically?
> Can't we (dummy) "initialize" them so there are placeholders to fall back to?
> I haven't looked in detail (sorry) and just saw the "trick GCC into" which
> might already indicate something like that?
> --
> Regards
> Robin
We could, but the builtin validation is done through the `fn_code`, and that
would likely not match the intrinsic that was statically written.
In other words, the validation would probably succeed because the `fn_code`
resolves to *some* builtin, but it could end up being a completely different
intrinsic than the one intended by the user.
I also tried with re-registering the APEX intrinsics before the validation step
runs, but I wasn't able to get that working.
>> The GCC canonical way of doing what APEX does would be
>> extern inline __attribute__((gnu_inline))
>> int foo_func (int a, int b)
>> {
>> int res;
>> __asm__ (".byte 7, XD" : "=r" (res) : "r" (a), "r" (b));
>> return res;
>> }
>> and I'd implement "fancy" (producing the appropriate register operand
>> mnemonic piece) via output templates and assembler extensions.
> That said, the extension is probably driven from the LLVM side
> where there's an internal assembler available. So even w/o that
> couldn't the target, upon parsing
> #pragma intrinsic (foo_func, "foo", 7, XD)
> generate the above inline function? Not sure if
> .extInstruction foo,7,XD
> is already the assembler extension required, if so then the
> asm template can just have "foo %0, %1, %2", no?
>> No need for #pragma or anything, it's just GCC extended asm and
>> function-as-a-macro extension. This should all work with LTO
>> already.
>> Richard.
This feature is indeed a port from a different proprietary LLVM-based compiler,
and one of our goals is to maintain both source and binary compatibility.
Using inline asm would very likely work well for the current use case. However,
we plan to extend this in the future with RVV and scheduling support, and
keeping a structured representation of the instruction in the compiler gives us
more flexibility for those extensions than lowering everything to inline asm.
It is also useful when a single intrinsic can map to multiple instruction
encodings (for example, xd/xs variants). In those cases, the compiler can
choose the appropriate instruction variant based on the operands, instead of
requiring the user to select and encode it manually in inline asm.
Regards,
Luis
