> 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.
Thanks for the feedback. We had considered this direction before and will take
another look at it.
Purely from a correctness perspective, the inline asm approach you suggested is
likely sufficient. Attempting to optimize the generated inline asm feels much
less clean than relying on builtins. But if you think that is a fine thing to
do, we will consider that approach.
One possibility would be to have the pragma generate a wrapper around a
statically defined builtin. For example:
extern int apex_func (int a, int b);
#pragma intrinsic(apex_func, "apexop", 27, "XD", "XS")
int apex_func (int a, int b)
{
return __builtin_riscv_apex ("apexop", 27, "XD", "XS", a, b);
}
In this model, we would provide a set of statically defined builtins (e.g. one
per operand count) and all state is encoded the the GIMPLE in some form.
A similar approach could also be implemented using inline assembly within the
wrapper, although that may become more complicated for RVV use cases.
If we can make this work cleanly, would you consider this approach acceptable?
-Luis
GF Confidential – Need to know
