Hardware interference size about cxx-abi HOT 2 OPEN

I gave a lightning talk about it at the 2018 dev meeting: https://llvm.org/devmtg/2018-10/talk-abstracts.html#lt12

There was a follow-up thread: http://lists.llvm.org/pipermail/cfe-dev/2018-October/059869.html

I believe there's wide agreement to the 9 point plan I outlined, and no current pushback. We just need to implement it:

1. Add to target infrastructure
2. Overriding in sub-targets using -march or -mcpu
3. Overriding on the command line
4. If set in target, expose the builtin
5. Generic le32 / be32 ARM targets expose constructive / destructive as 64B
6. Generic le64 / be64 ARM targets expose constructive as 64B and destructive as 128B
7. Generic x86 expose constructive / destructive as 64B
8. Honor existing sub-target preferences
9. Let maintainers of other targets choose appropriate size

from cxx-abi.

From the discussion around my implementation in GCC (not yet committed), I've come to the conclusion that we shouldn't try to make these values at all stable; they should have the appropriate values for what the compiler knows about the current target CPU (i.e. option 1 in that cfe-dev thread), and people should be strongly discouraged from using these variables in a context where ABI stability matters. At most, they should be used in an ABI shared between different TUs that are being built at the same time, with the same compiler flags. This policy allows them to work well for certain uses without trying to kind-of-almost accommodate dangerous uses.

To that end, I'm adding a warning if std::hardware_destructive_interference_size is constant-evaluated in a header.

I agree with @zygoloid in the cfe-dev thread above that using macros seems more natural than a builtin. Perhaps __CXA_DESTRUCTIVE_SIZE and __CXA_CONSTRUCTIVE_SIZE ?

from cxx-abi.