[Openmp-commits] [openmp] Mark as UNSUPPORTED some OMPT tests that fail on RISC-V (PR #156914)

[via Openmp-commits]

jprotze wrote:

Sorry, I somehow missed this PR. 
There exists code to handle different versions of RISCV64 codegen, so I would prefer fixing the test failures over just disabling them (since they presumably already worked for somebody):
https://github.com/llvm/llvm-project/blob/main/openmp/runtime/test/ompt/callback.h#L286

Here is how it's supposed to work. The code for `ompt/synchronization/barrier/explicit.c` after expanding the `print_current_address` macro:
```
#pragma omp barrier   // OpenMP-Codegen: ->  void __kmpc_barrier(ident_t *loc, kmp_int32 global_tid)
{}
__asm__("nop");
ompt_label_0:
print_possible_return_addresses(&&ompt_label_0);
```

You can find the test output somewhere in the build directory ... `openmp/runtime/test/ompt/synchronization/barrier/Output/explicit.c.tmp.out`. On my x86_64 machine, the output contains:
```
281474976710658: ompt_event_barrier_explicit_end: parallel_id=1000000000005, task_id=1000000000006, codeptr_ra=0x61e83f029721
281474976710658: current_address=0x61e83f029721 or 0x61e83f02971e for non-void functions
```
The value after codeptr_ra is the return address of the `__kmpc_barrier` function for above function call, i.e., the address of the instruction following the `call __kmpc_barrier` instruction, or whatever it is called in RISC-V. Dependent on the calling convention, the call instruction might be followed by some cleanup instructions. Therefore the ompt_label_* marks an instruction few bytes after the return address. The print statement in `print_possible_return_addresses` simply presents a list of different possible offsets between the return address and the instruction marked by the label. The main reason for this matching approach were limitations in FileCheck at the time when the tests were added. With current FileCheck we might find a more portable approach which would require modifying all related tests.

The OMPT tests might fail, if codegen/optimizations for a specific platform changes. The tests might also fail, if a new architecture with slightly different offsets is accidentally matched with the wrong architecture macro (just as compressed RISC-V).

There are two approaches for fixing the test failures: 
- Look into the test output, check where the codeptr_ra values don't match with any of the current_address values. Calculate the offset to any of the printed values and make sure that the expected value is printed in addition for your architecture.
- Look into the machine code generated for the test, calculate the offset between the instruction following the __kmpc_barrier call and the instruction marked with the label

Let me know if you have questions. 

https://github.com/llvm/llvm-project/pull/156914