I like the idea of the change, but there are some parts I don't understand yet. I've added inline comments.

Lgtm, thanks!

In D77743#1970035, @tra wrote:

Would not this scheme create a conflict between the device-side mangled kernel name and the handle which we emit with the same name? I recall that the distinct stub name was introduced specifically to avoid confusion between device-side kernel and the host-side stub that were visible at the same time (to debugger only?). Now we seen to re-introduce the same name only for the host-side handle instead of the host-side stub.

Somehow, details about the host architecture are creeping into the bogus target set up in MFCommon.inc. I've deleted the unit test to unblock the bots, until I can figure this out.

I disabled the unit test on Windows in 381bdd54.

Can we initialize it to kDynamicSize instead of hardcoded -1?

Added test case for Macho. Adjusted comments as suggested.

I see 'unknown file: error: SEH exception with code 0x3221225477 thrown in the test body', but don't know what causes this. It looks like this has come up before (https://reviews.llvm.org/rL329195, and http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180910/587425.html). I'll try testing locally with UBSan to see if that uncovers anything. If not I'll disable the test.

Clarify a comment

@mehdi_amini had forgotten to update the test, fixed.

LGTM. Thanks!

Adding more CMake people, but I'm all for this.

In D77740#1969886, @jyknight wrote:

I don't think there's any point in delaying until after the 11 release. We just branched LLVM 10. I believe we should make the change between now and the September LLVM 11 release, rather than afterwards.

I'd propose instead:

1. Add a warning like this -- but saying the minimum will be upgraded SOON, not in 11.0.0.
2. Keep the warning for a month -- meanwhile work on getting all buildbots upgraded
3. Promote the warning to an error, make sure buildbots are still working. Potentially revert and re-apply later, if there are issues.
4. Start cleaning up cruft for compat with old versions, yay!

Update the test to use the fused pass.

Thanks for handling this!

In D77740#1969886, @jyknight wrote:

I don't think there's any point in delaying until after the 11 release. We just branched LLVM 10. I believe we should make the change between now and the September LLVM 11 release, rather than afterwards.

LGTM

In D77370#1969771, @ldionne wrote:

Ok, let's go step by step to make sure we don't talk past each other. Here's some facts (feel free to correct me if you see a mistake):

1. CMake builds shared libraries with POSITION_INDEPENDENT_CODE=ON by default.
2. CMake builds static libraries with POSITION_INDEPENDENT_CODE=OFF by default.
3. Setting CMAKE_POSITION_INDEPENDENT_CODE=ON on the command-line or in a cache will cause CMake to build both shared libraries and static libraries with POSITION_INDEPENDENT_CODE=ON.