Using Clang for build and tests instead of GCC

[kgpai]

Hi Velox Community,

I am hoping to gather feedback on potential concerns , problems you might have if we migrate our builds and tests to use Clang instead of GCC on linux machines as it is now.

Why ?

This is so that we can have better reliability by enabling Address, Memory, Thread and Undefined behaviour sanitizers.
The advantages of adding sanitizers that is that :

1. We can get early signals on potentially unsafe changes before the merge process and thus reduce turnaround time.
2. With nightly fuzzer runs and plans for longer fuzzer runs - having sanitizers running with this gives us much better guarantees of reliability and stability.
3. Not all parts of Velox are tested internally at Meta (AWS/S3 support etc) - Ensuring these are also reliable , helps the community.

Why move to Clang

Currently Velox depends on Folly which unfortunately at the moment doesnt work that well with GCC Sanitizers. This is mostly because implementations of sanitizers in LLVM were ahead of implementations in GCC (This is true at least as of GCC 12). For example folly has perfectly sensible cases of atomic-compare-exchange operations with success-relaxed and failure-acquire memory orders, including in Baton and SaturatingSemaphore. But such pairs of memory orders are not permitted until C++17 and are permitted since C++17. But various implementations have not yet caught up, including the gcc sanitizers.

Next Steps

Should there be no major concerns, I propose to setup another CCI build which uses clang as the compiler for tests and fuzzer runs and then we only have GCC builds to ensure we maintain compatibility.

[kgpai]

cc: @pedroerp , @majetideepak , @aditi-pandit , @wanweiqiangintel , @mbasmanova , @assignUser

[assignUser]

+1 on using clang for the *san builds.

Could you clarify what job you want to move to clang/add?

[kgpai]

My proposal is to move all our tests / fuzzer tests to use clang (as sanitizers are only useful when things are run). We will still have a build with gcc to ensure that we are building things fine there but we will no longer run with the binaries build by GCC (to save on compute resources).

[majetideepak]

+1 as long as

we only have GCC builds to ensure we maintain compatibility

The GCC build scope should include tests and benchmarks as well.

[kgpai]

Yes, we will use GCC to build all targets (tests/ benchmarks/ python packages etc). However we probably wont run any of these binaries.

[pedroerp]

+1. I remember trying this locally in the past but bumping into something weird inside folly. Thanks for digging into the root cause.

Out of curiosity, do we have a sense of how clang and gcc build times compare for Velox?

[kgpai]

Hmm, Its not an apples to apples comparison since we use CLang on Macos and gcc on linux and I havent yet got clang building Velox on linux yet , but the build times are roughly similar in my experience. Should I see any significant variance I will let folks know.