Open mr-c opened 4 years ago
Seems that most of the time (> 75%) in these long Drone CI clang builds is spent in compiling tests/x86/gfni.{c,cpp}
If we can isolate some problematic code for clang we might be able to get them to take a look. Getting it fixed in clang would definitely be my preference...
Our slowest CI builds (as of https://github.com/nemequ/simde/commit/c0e36c9fa3a9dd6c104db71c3416e553e42c49b8 )
TravisCI; clang 3.8 on AMD64: 22 minutes Drone.io; clang-9 armv7: 30 minutes Drone.io; clang-9 armv8: 32 minutes Drone.io; clang-7 armv7: 20 minutes Drone.io; clang-7 armv8: 19 minutes
Alternatively: figure out why clang is so slow in these circumstances!
Travis already has caching turned on, and indeed, most of the 22 minutes for clang 3.8 is spent running the tests (why so slow?)
There is not built in support for caching in the free hosted instance, one has to provide their own (paid for) cloud credentials