Re: [PATCH] RISC-V: Add testcases for VSETVL PASS

[Jeff Law <jeffreyalaw@gmail.com>]

On 12/16/22 18:31, 钟居哲 wrote:
> Register allocation (RA) doesn't affect the assembler checks since I 
> relax the registers in assmebler checks,
> all assmebler checks have their own goal. For example:
> 
> The code like this:
> 
> +void foo2 (void * restrict in, void * restrict out, int n)
> +{
> +  for (int i = 0; i < n; i++)
> +    {
> +      vuint16mf4_t v = *(vuint16mf4_t*)(in + i);
> +      *(vuint16mf4_t*)(out + i) = v;
> +    }
> +}
> 
> Assembler check:
> 
> scan-assembler-times {vsetvli\s+(?:ra|[sgtf]p|t[0-6]|s[0-9]|s10|s11|a[0-7]),\s*zero,\s*e16,\s*mf4,\s*t[au],\s*m[au]\s+\.L[0-9]\:\s+vle16\.v\s+(?:v[0-9]|v[1-2][0-9]|v3[0-1]),0\s*\((?:ra|[sgtf]p|t[0-6]|s[0-9]|s10|s11|a[0-7])\
> 
> I don't care about which vector register is using since I relax register in assembler : (?:v[0-9]|v[1-2][0-9]|v3[0-1]), this means any vector register v0-v31
> 
> But also I relax scalar register : (?:ra|[sgtf]p|t[0-6]|s[0-9]|s10|s11|a[0-7]), so could be any x0 - x31 of them.
> 
> The only strict check is that make sure the vsetvl is hoist outside the loop meaning the location of vsetvl is outside of the Lable L[0-9]:
> 
> vsetvli\s+(?:ra|[sgtf]p|t[0-6]|s[0-9]|s10|s11|a[0-7]),\s*zero,\s*e16,\s*mf4,\s*t[au],\s*m[au]\s+\.L[0-9]
> 
> You can see the last assembler is \s+\.L[0-9] to make sure VSETVL PASS successfully do the optimization that hoist the vsetvl instruction outside the loop
> 
> I try to use check-function-body but it fails since it can not recognize the Lable which is most important for such cases.
Ah, I should have looked at those regexps closer.  Understood about the 
checking for hoisting the vsetvl.  Though it makes me wonder if we'd be 
better off dumping information out of the vsetvl pass.

In the case of hoisting we could dump the loop nest of the original 
evaluation block and the loop nest of the new vsetvl location, then we 
scan for those in the vsetvl pass dump.  While it doesn't check the 
assembly code, it's probably just as good if not better.

Consider that as an alternative.  But I'm not going to insist on it.  I 
just know we've had a lot of trouble through the years where assembly 
code changes slightly, causing test fails.  So I try to avoid too much 
assembly scanning if it can be avoided.  Often the easiest way to get 
the same basic effect is to dump at the transformation point and scan 
for those markers in the dump file.

Jeff