On 11/13/24 7:16 AM, Mariam Arutunian wrote:
On Tue, Nov 12, 2024 at 2:15 AM Jeff Law <jeffreya...@gmail.com
<mailto:jeffreya...@gmail.com>> wrote:
> +
> +
> +/* Generate assembly to calculate CRC using clmul instruction.
> + The following code will be generated when the CRC and data
sizes are equal:
> + li a4,quotient
> + li a5,polynomial
> + xor a0,a1,a0
> + clmul a0,a0,a4
> + srli a0,a0,crc_size
> + clmul a0,a0,a5
> + slli a0,a0,word_mode_size - crc_size
> + srli a0,a0,word_mode_size - crc_size
Not something you need to change. Aren't the final two instructions
here just a zero extension?
I suspect combine would pick this up. So it's probably not worth
adding
more conditionals in expander.
In the GCC code, after inserting the |clmul| instruction, I call |
riscv_emit_move (operands[0], gen_lowpart (crc_mode, a0)).
|I do not explicitly insert |slli| and |srli| instructions.
Zero extension is used in the early phases of the compilation, but
during the |split2| pass, it is replaced by |ashift| and |lshiftrt|
instructions.
OK. That all makes sense and I even more strongly suspect that all the
right things will happen if (for example) Zbb is turned on. Thanks for
clarifying.
> \ No newline at end of file
> diff --git a/gcc/testsuite/gcc.target/riscv/crc-1-zbkc.c b/gcc/
testsuite/gcc.target/riscv/crc-1-zbkc.c
> new file mode 100644
> index 00000000000..8c627c0431a
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/crc-1-zbkc.c
> @@ -0,0 +1,11 @@
> +/* { dg-do run } */
> +/* { dg-options "-fdump-tree-crc -fdump-rtl-dfinish -fdisable-
tree-phiopt2 -fdisable-tree-phiopt3" } */
> +/* { dg-additional-options "-march=rv64gc_zbkc" { target
{ rv64 } } } */
> +/* { dg-additional-options "-march=rv32gc_zbkc" { target
{ rv32 } } } */
So I think we probably need to add a bit of code to the testsuite.
Essentially we don't want to run this test on targets that don't have
zbkc support.
I think we probably end up wanting something similar to what we do with
vector where we have a test to tell us when V is supported. I'm
planning to pick that up. Similarly I think we want to do something
similar for Zbc.
To address this, I added code in |target-supports.exp| and modified the
relevant tests.
I've attached the patch. Could you please check whether it is correct?
I think that just tests if the compiler thinks the extension is enabled.
ie, did we pass Zbkb, Zbc or whatever on the command line. The
question we need to answer is whether or not we can run such code.
The way we've done that for the V extension looks like this:
proc check_effective_target_riscv_v_ok { } {
# If the target already supports v without any added options,
# we may assume we can execute just fine.
if { [check_effective_target_riscv_v] } {
return 1
}
# check if we can execute vector insns with the given hardware or
# simulator
set gcc_march [regsub {[[:alnum:]]*} [riscv_get_arch] &v]
if { [check_runtime ${gcc_march}_exec {
int main() { asm("vsetivli t0, 9, e8, m1, tu, ma"); return 0; } }
"-march=${gcc_march}"] } {
return 1
}
# Possible future extensions: If the target is a simulator, dg-add-options
# might change its config to make it allow vector insns, or we might use
# options to set special elf flags / sections to effect that.
return 0
}
So we compile a little program with a single vector instruction and
check that it doesn't fault. I was thinking we could do the same thing
for Zbc and Zbkb, but I haven't had time to cobble it together yet.
Jeff
