Create PQR instruction class

[LucasSte]

This PR creates the PQR instruction class for SBFv2, as it introduced in solana-labs/rbpf#498.
This is another task in solana-labs/solana#34250 to implement the SBFv2 changes in the LLVM backend.

I also tested these new instructions with all the programs in programs/sbf on the main repository. The only failure I got was a different instruction count, so I assume everything is working.

[seanyoung]

I think it would be nice to have a test for 256 bit mul, to ensure the codegen is good. Possibly with overflow detection too.

This change makes a big difference for NeonVM and Solang. It would nice to ensure it works as expected.

[LucasSte]

I think it would be nice to have a test for 256 bit mul, to ensure the codegen is good. Possibly with overflow detection too.

This change makes a big difference for NeonVM and Solang. It would nice to ensure it works as expected.

What do you mean by "codegen is good"? 256-bit multiplications generate many assembly instructions.

[seanyoung]

I think it would be nice to have a test for 256 bit mul, to ensure the codegen is good. Possibly with overflow detection too.
This change makes a big difference for NeonVM and Solang. It would nice to ensure it works as expected.

What do you mean by "codegen is good"? 256-bit multiplications generate many assembly instructions.

If the mulhu and mulhs instructions are used, it should be much shorter (about 30 instructions). A test would verify that those instructions are indeed used (and used correctly, of course).

[LucasSte]

I think it would be nice to have a test for 256 bit mul, to ensure the codegen is good. Possibly with overflow detection too.
This change makes a big difference for NeonVM and Solang. It would nice to ensure it works as expected.

What do you mean by "codegen is good"? 256-bit multiplications generate many assembly instructions.

If the mulhu and mulhs instructions are used, it should be much shorter (about 30 instructions). A test would verify that those instructions are indeed used (and used correctly, of course).

I'll include a test for that. Keep in mind that correctly breaking down 256-bit operations happens in LLVM's target independent code generation. This PR only matches the ISDOpCode MULHU/MULHS with the new instructions if ISDOpCodes are generated. Emitting mulhu or not for such a case is not something this PR addresses, as it is not related to the SBF backend.

The function below has more than 100 instructions and utilizes uhmul64 six times between many conditional jumps.

define i256 @try_mul(i256 noundef %a, i256 noundef %b) local_unnamed_addr #0 {
entry:
  %mul = mul i256 %a, %b
  ret i256 %mul
}

[seanyoung]

The function below has more than 100 instructions and utilizes uhmul64 six times between many conditional jumps.

define i256 @try_mul(i256 noundef %a, i256 noundef %b) local_unnamed_addr #0 {
entry:
  %mul = mul i256 %a, %b
  ret i256 %mul
}

That's broken then

[LucasSte]

The function below has more than 100 instructions and utilizes uhmul64 six times between many conditional jumps.

define i256 @try_mul(i256 noundef %a, i256 noundef %b) local_unnamed_addr #0 {
entry:
  %mul = mul i256 %a, %b
  ret i256 %mul
}

That's broken then

Ok, I'm not adding the test then. I counted 16 multiplications in total (10 lmul64 and 6 uhmu64). Maybe the algorithm is not as lean as we were expecting.

[dmakarov]

LGTM.