[PATCH] D111617: [RISCV] Lazily add RVV C intrinsics.

[Hsiangkai Wang via Phabricator via cfe-commits]

HsiangKai added a comment.

In D111617#3076994 <https://reviews.llvm.org/D111617#3076994>, @rogfer01 wrote:

> In D111617#3060377 <https://reviews.llvm.org/D111617#3060377>, @HsiangKai wrote:
>
>> Although it reduces the header size, this patch will increase the binary size of clang.
>
> Options we can consider to mitigate this:
>
> - See if we can be more economical reprenting the table itself

Yes, I agree. This primitive work has lots of space to improve. Most of the C intrinsics have the same argument lists. We could encode them in a table and reuse the same argument lists. In addition, we could use StringMatcher in the TableGen utilities to generate the switch cases to improve the performance. I am trying to implement this patch in a better way.

> - Store it in the binary in a format unsuitable for lookups (e.g. compressed) and then transform it (in memory) the first time is used so queries can be solved in a reasonable amount of time.
>
>> Or we should go back to think about the design of RVV intrinsics?
>
> Certainly the explosion of cases is an issue.
>
> Maybe an alternative is using overloaded builtins (similar to what atomic builtins can do when the type is not specified), but I understand this means implementing the typechecking itself. Which perhaps it can be generated too.
>
> This looks like it might bring a lot of reduction in cases and tables. Corner cases will appear when the arguments of a call are not enough to determine the precise intrinsic desired, e.g. loads as they are currently defined would be ambiguous between different LMUL types (though there may be ways to mitigate this, e.g. overload only within LMULs).




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111617/new/

https://reviews.llvm.org/D111617