4 ms·

You can do many thing with macros and inline namespaces but I believe they run into problems when modules come into play. Can you compile the same code twice, w

You can do many thing with macros and inline namespaces but I believe they run into problems when modules come into play. Can you compile the same code twice, with different flags with modules?

janwas 2y ago
We use pragma target instead of compiler flags :)
- dyaroshev 2y ago
  I don't think we understand each other. We want to take one function and compile it twice: ``` namespace MEGA_MACRO { void foo(std::span<int> s) { super_awesome_platform_specific_thing(s); } } // namespace MEGA_MACRO ``` Whatever you do - the code above has to be written once but compiled twice. In one file/in many files - doesn't matter. My point is - I don't think you can compile that code twice if you support modules.
  - janwas 2y ago
    I think I do understand, this is exactly what we do. (MEGA_MACRO == HWY_NAMESPACE) Then we have a table of function pointers to &AVX2::foo, &AVX3::foo etc. As long as the module exports one single thing, which either calls into or exports this table, I do not see how it is incompatible with building your project using modules enabled? (The way we compile the code twice is to re-include our source file, taking care that only the SIMD parts are actually seen by the compiler, and stuff like the module exports would only be compiled once.)
    - dyaroshev 2y ago
      > is to re-include our source file Yeah - that means your source file is never a module. We would really like eve to be modularized, the CI times are unbearable. I'd love to be proven wrong here, that'd be amazing. But I don't think google highway can be modularized.
      - janwas 2y ago
        What leads you to that conclusion? It is still possible to use #include in module implementations. We can use that to make the module implementation look like your example. Thus it ought to be possible, though I have not yet tried it.
        dyaroshev 2y ago
        Well. You have a file, something like: load.h You need to include it multiple times, compiled with different flags. So - it's never going to be in load.cxx or whatever that's called.
        janwas 2y ago
        As mentioned ("re-include our source file"), we are indeed able to put the SIMD code, as well as the self-#include of itself, in a load.cxx TU. Here is an example: https://github.com/google/gemma.cpp/blob/9dfe2a76be63bcfe679b94335f171674420f92e8/ops/bench_matmul.cc#L49 https://github.com/google/gemma.cpp/blob/9dfe2a76be63bcfe679...
        dyaroshev 2y ago
        I don't think this works if your files are modules. Let's stop here, it doesn't seem like we understand each other.
  - deleted 2y ago
    [deleted]

You can do many thing with macros and inline namespaces but I believe they run into problems when modules come into play. Can you compile the same code twice, with different flags with modules?

janwas 2y ago

We use pragma target instead of compiler flags :)

dyaroshev 2y ago
I don't think we understand each other. We want to take one function and compile it twice: ``` namespace MEGA_MACRO { void foo(std::span<int> s) { super_awesome_platform_specific_thing(s); } } // namespace MEGA_MACRO ``` Whatever you do - the code above has to be written once but compiled twice. In one file/in many files - doesn't matter. My point is - I don't think you can compile that code twice if you support modules.
- janwas 2y ago
  I think I do understand, this is exactly what we do. (MEGA_MACRO == HWY_NAMESPACE) Then we have a table of function pointers to &AVX2::foo, &AVX3::foo etc. As long as the module exports one single thing, which either calls into or exports this table, I do not see how it is incompatible with building your project using modules enabled? (The way we compile the code twice is to re-include our source file, taking care that only the SIMD parts are actually seen by the compiler, and stuff like the module exports would only be compiled once.)
  - dyaroshev 2y ago
    > is to re-include our source file Yeah - that means your source file is never a module. We would really like eve to be modularized, the CI times are unbearable. I'd love to be proven wrong here, that'd be amazing. But I don't think google highway can be modularized.
    - janwas 2y ago
      What leads you to that conclusion? It is still possible to use #include in module implementations. We can use that to make the module implementation look like your example. Thus it ought to be possible, though I have not yet tried it.
      - dyaroshev 2y ago
        Well. You have a file, something like: load.h You need to include it multiple times, compiled with different flags. So - it's never going to be in load.cxx or whatever that's called.
        janwas 2y ago
        As mentioned ("re-include our source file"), we are indeed able to put the SIMD code, as well as the self-#include of itself, in a load.cxx TU. Here is an example: https://github.com/google/gemma.cpp/blob/9dfe2a76be63bcfe679b94335f171674420f92e8/ops/bench_matmul.cc#L49 https://github.com/google/gemma.cpp/blob/9dfe2a76be63bcfe679...
        dyaroshev 2y ago
        I don't think this works if your files are modules. Let's stop here, it doesn't seem like we understand each other.
- deleted 2y ago
  [deleted]