On Mon, 8 Jun 2026, Silva, Luis wrote:
> 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.
Note the compiler would create the inline asm based on the #pragma
and there's print operand modifiers that can be used for xd/xs variants.
I think writing a compiler backend with #pramga is a very bad idea,
so whatever you want to do with scheduling, what's possible with
asm()s should be good enough. The target can always chose to
fold the asm back to sth more suitable if it likes - I did not look
into how you currently do this, but I can hardly think of sth
better than an UNSPEC_VOLATILE with arbitrary signature?
That said, NACK for the LTO part at this point, because the overall
design is not sound (IMO).
Richard.
> Regards,
> Luis
>
>
--
Richard Biener <[email protected]>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
