don't check if the SDK isn't present.

Sure, will do.

Please add a test-case as well.

LGTM.

I'll fix up Clang.Preprocessor::aarch64-target-features.c test this morning.

@t.p.northover @ab I noticed that the use of "apple-a12" doesn't infer the right target features when we're passing in a11 or older, so that's why my test file has the INFER-A12 separate line. Do you think this is a bug? This is decided here:

In D82428#2110506, @steven_wu wrote:

LGTM.

Not sure if it makes more sense to break the patch into two commits:

• config.guess change is for building the correct host triple on apple silicon machine without explicitly specify it.
• the driver change is for better default on Apple silicon Mac.

Can you still modify the state of -Wundef with #pragma clang diagnostic? Could you add a test to cover it.

In D79916#2039842, @dexonsmith wrote:

IOW, this LGTM if Alex and Gerolf are happy.

Added test and a comment.

Drop caching, it's not need for the speedup.

@jkorous it looks like dropping caching works too, this achieves similar perf results.

In D79834#2034666, @jkorous wrote:

IIUC the issue is that SourceManager::translateFile() basically consists of two blocks of code:

// First, check the main file ID, since it is common to look for a
// location in the main file.
if (MainFileID.isValid()) {
  bool Invalid = false;
  const SLocEntry &MainSLoc = getSLocEntry(MainFileID, &Invalid);
  if (Invalid)
    return FileID();

  if (MainSLoc.isFile()) {
    const ContentCache *MainContentCache =
        MainSLoc.getFile().getContentCache();
    if (MainContentCache && MainContentCache->OrigEntry == SourceFile)
      return MainFileID;
  }
}

and

  // The location we're looking for isn't in the main file; look
  // through all of the local source locations.
...

The comments suggest that the first block is a heuristic related to our case and the second block I would assume being the expensive part. SourceManager::getFileEntryRefForID implementation seems similar to the first block.

It makes sense to me to avoid the expensive search. I'm just wondering - how much speedup do we get with caching the value?

fix assertion in the unit test.

LGTM. Looks like we don't have tests for this script, it would be nice to add some in the future, but that shouldn't block this.

This is also failing on our expensive checks bot http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-expensive/ FYI

Unfortunately this change causes the following failure for a clang that's built with LLVM_EXPENSIVE_CHECKS=On when building compiler-rt for armv7k:

Great, that looks better, thanks! LGTM

LGTM with one comment that needs to be fixed

It looks like you're now adding a dependency on a real filesystem to the VFS writer due to calls to fs::is_directory. I think it should be possible to use a VFS write to construct a VFS file without an underlying filesystem, or with an underlying filesystem that doesn't represent the state of your constructed VFS. Is there another way to achieve this goal without depending on the underlying filesystem?

In D75849#1942382, @arphaman wrote:

Hi @graywolf-at-work, @dvyukov

This change causes compiler-rt to fail to build lib/CMakeFiles/SanitizerLintCheck on Darwin with the following error:

clang-11: warning: include path for libstdc++ headers not found; pass '-stdlib=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found]
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: race_darwin_amd64.syso: No such file or directory.

Example: http://lab.llvm.org:8080/green/job/clang-stage1-RA/7900/consoleFull#-87031640a1ca8a51-895e-46c6-af87-ce24fa4cd561

Can you please take a look at this issue as soon as you can? Let me know if you need help reproducing this.

This change causes compiler-rt to fail to build lib/CMakeFiles/SanitizerLintCheck on Darwin with the following error: