https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110812
--- Comment #14 from Robin Dapp <rdapp at gcc dot gnu.org> --- I managed to have a look now but the whole builtin and LTO machinery is kind of new to me. As Andreas mentioned already the issue is that we do not register vector builtins when the current target is !TARGET_VECTOR. This we can easily change but as we also don't enable the respective vector modes various builtin builder functions don't work. On top we deactivate certain modes depending on the current minimum vector length. Without V extension we default to a "minimum vector length" of 4 bytes which disables certain smaller vector modes. Those, in turn, need to be active when compiling another TU with the standard V extension. Also there are mutually exclusive requirements so we cannot just always enable everything and then decide at expansion time. I'm afraid I'm lacking background in LTO land - how is this supposed to work in general? If we lto compile one TU/CU with vector and another one without, while the final step does not have vector, what is the expected behavior? If one function uses vector and a vector mode that is not available in a default setting what are we supposed to do? We could set slightly other defaults, i.e. "rv64gcv" implicitly for builtin init? When compiling multiple TUs with different arch options the final executable will require the union of all those I presume?
