On 11/22/24 10:33 AM, Mariam Arutunian wrote:
On Fri, Nov 22, 2024, 20:29 Jeff Law <jeffreya...@gmail.com
<mailto:jeffreya...@gmail.com>> wrote:
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>
> <mailto:jeffreya...@gmail.com <mailto:jeffreya...@gmail.com>>> wrote:
>
>
> > \ 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.
I have written similar code for ZBC, ZBKC, and ZBB, and in my previous
reply, I attached the patch containing that code.
Here is a part from that patch:
+proc check_effective_target_riscv_zbc_ok { } {
+ # If the target already supports zbc without any added options,
+ # we may assume we can execute just fine.
+ if { [check_effective_target_riscv_zbc] } {
+ return 1
+ }
+
+ # check if we can execute zbc insns with the given hardware or
+ # simulator
+ set gcc_march [riscv_get_arch]
+ if { [check_runtime ${gcc_march}_zbc_exec {
+ int main()
+ {
+ asm ("clmul a0,a0,a1");
+ asm ("clmulh a0,a0,a1");
+ return 0;
+ } } "-march=${gcc_march}"] } {
+ return 1
+ }
+ return 0
Oh, that's exactly what I was expecting. Maybe I just didn't read down
far enough.
Jeff
