Hi Sandra,
Am 16.07.24 um 19:03 schrieb Sandra Loosemore:
Well, I still do not understand why backward compatibility concerns
specific to some other directive should affect the ABI for a new
directive that does not have any current libgomp runtime support,
I am happy that I managed to explain you the background of the "-1"
mess. Otherwise:
The backward-compatibility hack is not required, but it has two
advantages: consistency of the values used and it makes the code inside
target.c way simpler by just using
struct gomp_device_descr *devicep = resolve_device (device, true);
instead of handling several additional cases.
However, as written, avoiding the '(n == -1) ? -2 : n' code generation
also has advantages; hence, I am also happy with that variant. (i.e. -2
or -3 denoting the default device).
However, if you use -2 == default device, you need to fix the
libgomp/target.c implementation as your code doesn't handle
omp_default_device correctly, which 'resolve_device (device, true);'
would handle automatically.
you just tell me what ABI you want me to implement and I will re-do
the code that way.
Having looked at the code again – and in particular at libgomp/target.c,
I realized the merits of using -2. Thus, at the end, I am happy with
*either* variant.
But either version requires some changes: One the creation of the
conditional gimple code + much simplified code in target.c. And the
other, keeping the current gimple code – but fixing/extending target.c.
Tobias
