The first thing to do is to look at the manual that accompanies the code. (See http://llvm.org/svn/llvm-project/openmp/trunk/runtime/doc/ or the equivalent place in your checked out code). It should clearly be updated (since it hasn’t been built since 2015); maybe this could be your first commit request…), but it does try to give you some introduction. For scheduling look at the chapter on Work Sharing. That also points you at the functions you should be interested in, and the enumerations which list the supported schedules.
I expect that your new schedules will need to use the dynamic schedule interface, since that has a call into the runtime for each chunk of iterations a thread should execute, whereas the static schedule interface calls the runtime only once, then computes the iteration locally from the chunked block-cyclic distribution described by that initial call.
For prototyping purposes, it is probably easiest to add some new call of your own (do not use the omp_* namespace!) to set a flag inside the runtime that you can then check in the dynamic loop initialization code to choose your schedule at the next dynamic loop.
So, something like
#pragma omp for schedule(dynamic)
… etc …
You’d then also need to define ay_set_schedule_magic() somewhere in the runtime and export it, and also have a null version of that in another shared library so that you can to the comparison between your code and the existing schedules on the same executable.
You could just force all dynamic loops to use your new schedule (via some envirable you checked for), but that may be more confusing, since it’s harder to do experiments on real code with many dynamic loops.
If you want to do history based scheduling (remembering how a particular lexical loop behaved and using that information the next time it is executed), note that the first argument to all of these functions is a pointer to an ident_t which, in turn, points to a source location string. (With the Intel compiler you need to compile the code with –parallel-source-info=2 to get the full filename in there; I’m not sure what LLVM does about that). Without that flag there is still some source info it’s just not complete.
(Hmm… it looks as if clang puts in the source file info without requiring extra compiler flags, look at https://godbolt.org/z/HseSot and note the
(If you’re not familiar with the compiler explorer, it may prove useful to you as a quick way to see what code is generated for a given OpenMP construct).
Good luck, and keep asking.