On Tue, 23 Jun 2020 11:22:44 +0800, Kito Cheng <kito.cheng@...> said:

| Hi

Hi Kito,

|| 3) Spill code inside loop
||
|| This is the most problematic case. I wonder about how often the
|| compiler does not know the type and length of the values to be
|| restored? I agree adding EEW to the whole-register move could help
|| here, and doesn't add complexity to simpler implementations which can
|| ignore it.

| Some point from compiler developer's view, we've implemented spill
| code gen with whole register load/store on GCC.

| Compiler/GCC know the type when spilling register but length (AVL) is
| unknown during generating spilling code, also confirmed with LLVM
| folks, there is same situation as GCC, and compiler also know the
| whole register move/load/store won't use vtpe and vl, so there won't
| generate extra vsetvl[i] around spill code.

| I think EEW=8 for whole register load/store doesn't matter for
| compiler, since the compiler only care the content can be
| saved/restored, so I am not sure the usage for (another) EEW
| whole-register move/load/store on the compiler side.

The EEW in the whole register load is a hint to aid wide
microarchitectures in organizing data internally. If the compiler can
put the correct EEW on the whole register load, then the microarch can
avoid an internal rearrangement on the first use with different EEW.
It is only a hint, which doesn't change functional behavior but could
affect performance. If the compiler (or other software) doesn't know
the value then everything still works, just possibly with an internal
performance hiccup.

| The only concern is the debugging scenarios, while a value spilled
| into memory and debugger want to print out its content from memory,
| debugger might not know how to interpret that if VLEN != SLEN, the
| solution I can imagine is load it into vector register and then set
| the vtype correctly.

I think debugger issue is yet another reason to fix on SLEN=VLEN
format.

Krste

| On Tue, Jun 23, 2020 at 9:06 AM Bill Huffman <huffman@...> wrote:
||
||
||
|| On 6/22/20 5:26 PM, Krste Asanovic wrote:
|| > EXTERNAL MAIL
|| >
|| >
|| >
|| >> On Jun 22, 2020, at 4:56 PM, Bill Huffman <huffman@...> wrote:
|| >>
|| >> On 6/21/20 11:55 PM, krste@... wrote:
|| >>> EXTERNAL MAIL
|| >>
|| >>>
|| >>> I still understand the desire to include expected sew tag in load
|| >>> instructions, but am trying to find a solution that doesn't require a
|| >>> microarchitectural hint.
|| >>>
|| >>> Krste
|| >>
|| >> Well, if you can think of one, great. But I don't think either of the
|| >> above is usable.
|| >>
|| >> Why is there an issue putting the size in the whole register load
|| >> instructions? Seems trivial to me. Especially if it enables removing
|| >> the SLEN parameter entirely from the spec.
|| >>
|| >> Bill
|| >
|| > I agree it’s difficult to find an alternative, and I am OK with having this as an architected hint.
|| >
|| > Dropping SLEN completely is a major win.
|| >
|| > Krste
||
|| It's a lesser issue, as you said, but the millicode case might want a
|| single store and single load of whole registers that expects prediction
|| in addition to the single whole register store and hint-ed whole
|| register load that don't expect prediction.
||
|| That may depend on how much use of millicode routines is expected - or
|| at least millicode routines that need to use callee-saved registers.
||
|| Bill
||
|| >
|| >
|| >
|| >
|| >
||
||