[llvm] [Support] Always call FlushFileBuffers() when unmapping memory on Windows (PR #78597)

[Martin Storsjö via llvm-commits]

mstorsjo wrote:

> @mstorsjo Are you able to test linking a large PDB by chance? 4GB+ PDB are becoming quite common nowadays, and since the PDB isn’t needed just after link, the previous optimization I did was saving several seconds of link time.

I don't have any such scenarios available to test off the bat at least. To understand - what bit is it that takes the extra time in that case? Does `FlushFileBuffers()` force flushing the large PDB to actual disk, while it otherwise only would keep it in disk cache in memory (and maybe not flush it to disk at all in the end, if it doesn't end up used/needed)?

> Corectness is needed before performance, but this PR would impact cases which don’t need the flush (I assume most of LLD usages on Windows). Can we rather detect problematic cases on LLD startup, like writing to a virtual/network drive, and only disable the optimization there?

I'm not sure how we would detect those problematic cases. We could use the same heuristic that we use elsewhere, `is_local`, which we use internally in `setDeleteDisposition`. As we saw in the PR about using `FileIndex` vs hashing the path, `is_local` can be expensive though, but here we only operate on a few files, not many like clang inputs, so the heuristic would probably still be cheaper than writing a 4 GB PDB to disk. On the file we use in this case in LLD, we will already have called `setDeleteDisposition` though, but that information isn't available later when doing the unmapping, unless we try to propagate and pass that information through somehow.

https://github.com/llvm/llvm-project/pull/78597