On Thu, 13 Apr 2023, Richard Biener via Gcc-patches wrote: > On Thu, 13 Apr 2023, Richard Sandiford wrote: > > > ??? <juzhe.zh...@rivai.ai> writes: > > > Yeah, like kito said. > > > Turns out the tuple type model in ARM SVE is the optimal solution for RVV. > > > And we like ARM SVE style implmentation. > > > > > > And now we see swapping rtx_code and mode in rtx_def can make rtx_def > > > overal not exceed 64 bit. > > > But it seems that there is still problem in tree_type_common and > > > tree_decl_common, is that right? > > > > I thought upthread we had a way forward for tree_type_common and > > tree_decl_common too, but maybe I only convinced myself. :) > > > > > After several trys (remove all redundant TI/TF vector modes and FP16 > > > vector mode), now there are 252 modes > > > in RISC-V port. Basically, I can keep supporting new RVV intrinsisc > > > features recently. > > > However, we can't support more in the future, for example, FP16 vector, > > > BF16 vector, matrix modes, VLS modes,...etc. > > > > I agree it doesn't make sense to try to squeeze modes out like this. > > It's a bit artificial, and like you say, it's likely only putting > > off the inevitable. > > Agreed. Let's do the proposed TYPE_PRECISION change first and then > see how bad 16bit mode will be.
(I don't see the following obvious having been pointed out, or why it doesn't apply, but if so, I hope you don't mind repeating it, so:) If after all, a change to the size of the code and mode bit-fields in rtx_def is necessary, like to still fit 64 bytes such become non-byte sizes *and* that matters for compilation time, can that change please be made target-dependent? Not as in set by a target macro, but rather deduced from the number of modes defined by the target? After all, that number is readily available (or if there's an order problem seems likely to easily be made available to the rtx_def build-time definition (as opposed to a gen-* -time definition). brgds, H-P
