Pour obtenir une clé
d'essai remplissez le formulaire ci-dessous
Demandez des tariffs
Nouvelle licence
Renouvellement de licence
--Sélectionnez la devise--
USD
EUR
RUB
* En cliquant sur ce bouton, vous acceptez notre politique de confidentialité

Free PVS-Studio license for Microsoft MVP specialists
To get the licence for your open-source project, please fill out this form
** En cliquant sur ce bouton, vous acceptez notre politique de confidentialité.

I am interested to try it on the platforms:
** En cliquant sur ce bouton, vous acceptez notre politique de confidentialité.

Votre message a été envoyé.

Nous vous répondrons à


Si vous n'avez toujours pas reçu de réponse, vérifiez votre dossier
Spam/Junk et cliquez sur le bouton "Not Spam".
De cette façon, vous ne manquerez la réponse de notre équipe.

>
>
>
PVS-Studio team: switching to Clang imp…

PVS-Studio team: switching to Clang improved PVS-Studio C++ analyzer's performance

31 Mai 2021

From the earliest days, we used MSVC to compile the PVS-Studio C++ analyzer for Windows - then, in 2006, known as Viva64, version 1.00. With new releases, the analyzer's C++ core learned to work on Linux and macOS, and we modified the project's structure to support CMake. However, we kept using the MSVC compiler to build the analyzer's version for Windows. Then, in 2019, on April 29th, Visual Studio developers announced they had included the LLVM utilities and Clang compiler in the IDE. And just recently we've gotten around to try it.

0830_Clang-build/image1.png

Performance testing

We chose SelfTester - our utility for the analyzer's regression testing - as a benchmark. The utility analyzes a set of various projects and compares analysis results with reference values. For example, if the analyzer's core analysis showed new false positives or stopped showing applicable ones, this would mean the latest changes to the core caused some regression that needs to be fixed. To learn more about SelfTester, see the following article: "The Best is the Enemy of the Good".

The test base's projects vary in code volume quite a bit. Normally, when the running computer or test server is not overloaded, it takes SelfTester the same time - within the margin of error - to test the core of the same version. If the analyzer's productivity suffers, this significantly increases the overall testing time.

After we switched the C++ analyzer to the Clang compiler, SelfTester runs C++ core tests 11 minutes faster.

0830_Clang-build/image2.png

This means a 13% performance gain. That's quite significant, considering the only change was the compiler, don't you think?

Of course, there are disadvantages - but those are minor. The distribution's build slowed down by 8 minutes, and the executable file's size increased by 1.6 Mbytes - of those, 500 Kbytes come from static runtime linking.

0830_Clang-build/image3.png

Apparently, better performance is achieved by means of a longer LTO stage, that takes up most of the build time, and more aggressive loop unrolling and function inlining.

Now I'd like to talk more about issues we faced during the transition.

Generate a build for Clang

CMake scripts allow us to build code with all mainstream compilers, for required operating systems.

First, we used Visual Studio Installer to install the Clang compiler's components.

0830_Clang-build/image4.png

Clang-cl is a so-called "driver" that allows you to use clang with parameters from cl.exe. We expected clang-cl to interact with MSBuild transparently, almost like a native compiler.

Alternatively, we could have used official builds from the LLVM project. You can find them in their GitHub repository. However, they require an additional plugin so that Visual Studio could find the compilers. We chose the first route, so the toolset in examples below will be clangcl. If we used LLVM, the toolset name would have been llvm instead.

We specified toolchain in the solution generation command for Visual Studio:

cmake -G "Visual Studio 16 2019" -Tclangcl <src>

Alternatively, we could use GUI:

0830_Clang-build/image5.png

Then we opened the resulting project, built it - and got all these errors.

0830_Clang-build/image6.png

Fix the build

Although clang-cl looks and behaves like CL, under the hood it is a completely different compiler, with its own quirks.

We usually don't ignore compiler warnings, which is why we use /W4 and /WX flags. However, Clang may generate additional warnings that prevent the build from succeeding. That's why we temporarily deactivated them:

if (CMAKE_CXX_COMPILER_ID MATCHES "Clang")
  ....

  if (WIN32)
    add_compile_options(-Wno-error=deprecated-declarations
                        -Wno-error=reorder-ctor
                        -Wno-error=format-security
                        -Wno-error=macro-redefined
                        -Wno-error=bitwise-op-parentheses
                        -Wno-error=missing-field-initializers
                        -Wno-error=overloaded-virtual
                        -Wno-error=invalid-source-encoding
                        -Wno-error=multichar
                        -Wno-unused-local-typedef
                        -Wno-c++11-narrowing)
  ....
  endif()
endif()
0830_Clang-build/image8.png

Now that's better.

The GCC and Clang compilers, as opposed to MSVC for Windows, support the int128 type out-of-the-box. This is why a while ago PVS-Studio received an Int128 wrapper for Windows. The wrapper is written as inline assembly code wrapped in ifdef - in the best C/C++ traditions. Then we fixed preprocessor definitions. We replaced the code below

if (MSVC)
  set(DEFAULT_INT128_ASM ON)
else ()
  set(DEFAULT_INT128_ASM OFF)
endif ()

with the following:

if (MSVC AND NOT CMAKE_CXX_COMPILER_ID MATCHES "Clang")
  set(DEFAULT_INT128_ASM ON)
else ()
  set(DEFAULT_INT128_ASM OFF)
endif ()
0830_Clang-build/image9.png

Usually, the compiler driver, be it clang.exe or clang-cl.exe, passes a library with built-ins to the linker (lld). However, in this case MSBuild controlled the linker directly and did not know that the library was required. Consequently, the driver had no way to pass flags to the linker. So we handled the situation manually.

if (CMAKE_GENERATOR MATCHES "Visual Studio")

  link_libraries("$(LLVMInstallDir)\\lib\\clang\\\
${CMAKE_CXX_COMPILER_VERSION}\\lib\\windows\\\
clang_rt.builtins-x86_64.lib")

else()
  link_libraries(clang_rt.builtins-x86_64)
endif()
0830_Clang-build/image10.png

Yay! The build worked! However, when running tests, we encountered many segmentation faults:

0830_Clang-build/image12.png

The debugger was showing some strange value in IntegerInterval, while the problem was a bit further:

0830_Clang-build/image13.png

The data-flow mechanism's structures actively used the Int128 type we discussed earlier. The structures employed SIMD instructions to work with this type. The crashes were caused by an unaligned address:

0830_Clang-build/image15.png

The MOVAPS instruction moved a set of floating-point numbers to SIMD operation registers. For this operation to be successful, the address must be aligned and must end with 0. However, the address ended in 8. Here we had to help the compiler by setting the correct alignment:

class alignas(16) Int128
0830_Clang-build/image17.png

Looks good.

The last problem was prompted by Docker containers:

0830_Clang-build/image19.png

When generating builds for MSVC, we'd always employ static runtime linking that we had switched to dynamic for our Clang experiments. It turned out that Microsoft Visual C++ Redistributables were not included into Windows images by default. We decided to switch back to static linking so that our users wouldn't encounter the same challenges.

Conclusion

Although the project's preparation took a while, we were satisfied that the analyzer's performance grew by over 10%.

We will use Clang to build future releases of PVS-Studio for Windows.

Comments (0)

Next comments
Unicorn with delicious cookie
Nous utilisons des cookies pour améliorer votre expérience de navigation. En savoir plus
Accepter