I am a complete beginner to llvm, I must say the getting started with systems engineering is possibly the hardest part I mean the setup and configuration. I followed [Setup page with Visual Studio ] and it was not only intimidating but also unnecessarily complex and stressful. With that I hope they make the beginner’s journey little less harder, The build log suggests there are some unexpected errors can you please help me resolve those, I did exactly as mentioned in the setup page and got the following log,
What exactly are you trying to achieve? Do you want to use the LLVM libraries or do you just want get the clang compiler? Could you paste the exact cmake command line agruments? Do you need the latest LLVM or could you use the release branch?
I want to start with compiler engineering and optimization, I need to learn it and get started writing a basic optimization pass, youtube tutorials from llvm channel aren’t very helpful from what I’ve explored so far, there is almost no video out there that does step by step walk through on windows OS for llvm with Visual Studio, If you do have any please do send it. I followed exactly as told visual studio and llvm setup and I got the above log, it seems a quite lot of tests have failed and I don’t know why or how, so how do I fix those and how do I get started writing a basic optimization using llvm?
Two very different questions! I’ll address only the first. It may be that when you cloned the repository, there was a bug that caused the 81 failures. The first thing to try is doing git pull --rebase and then do the build and test steps again; refreshing your copy of the sources might get you the fix you need.
That said, I have also seen a number of complaints about our Windows instructions, and I am suspicious that there is something wrong there (a bug in the instructions, if you will). I will try following the instructions myself, as naively as possible, and see what happens.
Because I already had a VS2019 environment installed, I started with the “git clone” instruction, did the cmake command-line step, and build the check-all target. I see 18 test failures. I haven’t had a chance to look at them in detail, it might not happen until next week, but now I am interested in getting to the bottom of this.
It looks like I have core.autocrlf=input. I ran a build using ninja instead of msdev, on the same clone, and it doesn’t get these failures. Well, shtest-format.py and shtest-run-at-line.py still fail, but the other 16 pass.
The failures I see under msdev look like they’re all PDB-related, if that helps.
All 16 of the failures (i.e., all but the two tests of lit itself) depend on the DIA SDK. MSVC_DIA_SDK_DIR is set the same way in both my ninja and msdev builds. I did use -Thost=x64 when running cmake for the msdev build. The CMake code to handle DIA is in llvm\cmake\config-ix.cmake.
I see two copies of msdia140.dll in my MSVC 2019 installation. I don’t know why the ninja build can find the right one and the msdev build can’t.
@rnk any thoughts here? Or suggestions of who else to ask?
In the short term, to prevent this type of breakage, I think we should stop trying to autodetect DIA by default in CMake. It’s too fragile and prone to breakage. It used to be registered globally with some COM magic, but then Microsoft stopped doing that, and I don’t know the current status, and we shouldn’t care too much. As much as possible, LLVM should build and pass tests out of the box, and one way to achieve that is to cut unreliable third party dependencies.
We no longer depend on DIA for any critical functionality. llvm-symbolizer was the last major dependency, and I believe Amy Huang finished migrating from DIA to our native PDB reading code. Enabling DIA mainly gives you access to extra PDB dumpers, and those just don’t matter that much in the scheme of things.
In the long term, we might want to delete the DIA codepaths altogether. There was some idea that we could reimplement the abstractions that DIA provided, but what we (Zachary Turner & Adrian McCarthy) found in practice was that the abstractions weren’t a great match for the data or what we needed from it, so the native LLDB plugin bypasses a lot of the IPDB APIs that wrap DIA.
I’ll discuss this more with Zequan Wu who is currently working on LLDB support for PDBs.
This problem seems to be specific to running tests under MSDEV (e.g., doing Build on the check-all project) and in particular, if I run them using llvm-lit.py in the exact same build tree, they all pass. I don’t think DIA itself is the problem; it’s how MSDEV goes about finding DIA.
It could be registered manually, from a VS2019 cmd shell run as administrator: > regsvr32 "%vsinstalldir%\dia sdk\bin\amd64\msdia140.dll"
Then all the DIA-using tests pass fine.
The other alternative is to update the website instructions so they don’t tell you to build check-all from the IDE (although we’d have to substitute an instruction for how to build everything… check-all does that as a side effect, would all-targets be the right thing to substitute? I don’t know how the IDE projects are organized). Instead, we’d have to tell people to run the tests from a VS2019 cmd shell.