On Fri, 14 Apr 2023, Hans-Peter Nilsson wrote: > 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).
But it gets us in the "wrong" direction with the goal of having pluggable targets (aka a multi-target compiler)? Anyway, I suggest we'll see how the space requirements work out. We should definitely try hard to put the fields on a byte boundary so accesses become at most a load + and. Richard.
