On Dec 6, 2023, Thomas Schwinge <tho...@codesourcery.com> wrote:
> As I understand things, this cannot be implemented (at the call site) for
> nvptx, given that the callee's stack is not visible there: PTX is unusual
> in that the concept of a "standard" stack isn't exposed.
Not even when one PTX function calls another? Interesting. I'd hoped
that with control over entering and leaving strub contexts, one could
(manually) ensure they'd run in the same execution domain. But if not
even that is possible, it will render the current strub implementation
entirely unusable for this target indeed.
Now, it doesn't seem to me that the build errors being experienced have
to do with that, but rather with lack of or incomplete support for
__builtin_{frame,stack}_address(). Are those errors expected when using
these builtins on this target? I'd have expected them to compile, even
if something went wrong at runtime.
> Instead of allowing "strub" pieces that can be implemented, should this
> whole machinery generally be disabled (forced '-fstrub=disable', or via a
> new target hook?)? The libgcc functions should then not get defined
> (thus, linker error upon accidental use), or should just '__builtin_trap'
> if that makes more sense? Need an effective-target for the test cases.
> Alternatively, we may also leave the generic middle end handling alive,
> and 'sorry' (or similar) in the nvptx back end, as necessary?
Disabling the runtime bits is easy, once we determine what condition we
wish to test for. I suppose testing for target support in the compiler,
issuing a 'sorry' in case the feature is required, would provide
something for libgcc configure and testsuite effective-target to test
for and decide whether to enable runtime support and run the tests.
--
Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
