Fix @rsmith s comments, rebase on the big CPUDispatch refactor.

Submitter: Any update on the status? It seems that Richard's feedback should be trivial enough, so I was wondering if you need this taken up?

In D54547#1301351, @voskresensky.vladimir wrote:

I have some experience with PTH implementation, because had to fix it for Java-port of Clang (https://github.com/java-port/clank).

It was sometime ago, but making it completely workable was not hard.
As I remember the key fix was just to have PTH be EMITTED using raw-Lex mode (where real keyword-IDs are not used, so all Token Kinds nicely fit 8-bits).
It worked, because on token automatically became keyword by PTHLexer::Lex:
...

   // Change the kind of this identifier to the appropriate token kind, e.g.
   // turning "for" into a keyword.
Tok.setKind(II->getTokenID());

...

We used PTH, because multiple translation units are parsed in the context of single run.
In this case preprocessing phase was upto 10x faster when token stream was deserialized from PTH (i.e. for all system headers lexed once).
Also it was helpful, because we were able to parse from concurrent threads using the same shared immutable mmaped PTH.

I thought clang-d service is using it to speed up indexing.

In D54547#1301253, @arphaman wrote:

Would it be better to deprecate the use of PTH right now for the current release, so that the users will be aware that we will remove PTH support in LLVM 9 once they upgrade to LLVM 8? Then we can remove it right after LLVM 8 branch is created.

Added to the release notes. Also, an email was sent out to cfe-dev.

You'll not be able to get the C++ spelling without it getting into the standard. Additionally, it seems easy enough to calculate upon need, so storing it in the AST is a waste. @aaron.ballman is likely another person who can review this.

rL345302

Add to the test

In D53718#1276205, @zturner wrote:

Will this work for the following variable?

constexpr int N = 3;

In D53586#1276198, @rnk wrote:

Here's a thought. What happens if different TUs observe different overload sets, perhaps because of ifdefs? Different TUs will generate different resolvers, but they won't dispatch to the same sets of targets. I'm guessing we'd treat that as an ODR violation, no diagnostic required?

Anyway, I think this is ready to commit. Thanks!

In D40925#1276114, @rnk wrote:

My coworker, @zturner, asked if I knew a way to force emit all constants, and I mentioned this flag, but we noticed it doesn't work on cases when the constant is implicitly static, like this:

const int foo = 42;

If I add static to it, it gets emitted with -fkeep-static-consts, but as is, it doesn't get emitted.

Do you think it's worth extending the logic to handle this case? GCC seems to that global foo regardless of the flag setting.

Update the 2 failing tests. Would love some help looking at the Analysis fix, it seems to no longer have to 'assume' stuff due to the this now being defined behavior.

Woops, apparently a couple of tests fail on this that I somehow missed the 1st time. Looking into it.

ACTUALLY add the test this time :/ sorry about that!

Added test as requested by @rnk. How's it look? I hope I got the balance of check-lines right.

did everything suggested by @rnk as far as I know. Thanks again for the reviews!

@rnk: I looked into the EmitMustTailThunk code, and don't terribly see what I'm doing wrong. I clearly cannot CALL that function (since this works with non-CXXMethodDecls), so I looked into using it. However, I saw that it does a couple of small things that seem useful, but not anything that seems to fix your concerns.

In D53586#1273546, @rnk wrote:

Seems reasonable. Should the resolver still be called ?foo@.resolver, or should it get a new name, since it is quite functionally different now?

Yikes, good catch!

Superseding with a version that seems to work

@aaron.ballman or @rsmith any chance you guys could give me a hand on the direction here? I'm growing GlobalDecl by quite a bit, so I want to make sure this is both permissible and the right way to go. Additionally, feedback on how to get a GlobalDecl down to getFunctionFeatureMap would be appreciated.

Can you write tests for this please? Particularly validate the results in a constexpr context.

In D46535#1253473, @xbolva00 wrote:

Hello, @erichkeane

I am working on int to float checker but I haven't found yet a way how to check if integer fits to float's significant bits. Maybe you can recommend me something? I already tried some LLVM APIs but no success. (cc @spatel as you will probably know the right function to do it)

In D52268#1239557, @riccibruno wrote:

In D52268#1239538, @erichkeane wrote:

Does this still work with 32 bit hosts? Does PointerIntPair have 3 bits in that case? Is the alignof static_assert valid in that case?

I think it does since Decl is manually over-aligned to 8 bytes. But you are right that the static_assert is probably not needed
here since llvm::PointerIntPair checks that the low bits are available.

I'm not sure how often this ever gets modified, but it is a touch scary to me that we've already maxed out the size of this struct.

I am not sure either... It was just a quick change I spotted and this is borderline not worth doing. If you think that we ought to keep
some space left I will abandon this revision.

Does this still work with 32 bit hosts? Does PointerIntPair have 3 bits in that case? Is the alignof static_assert valid in that case?

A few drive-by comments... This is a patch with interactions I'm not sure I feel comfortable approving myself, so I'll count on @rjmccall to do so.

Thanks for the feedback @rsmith! I'm working through the lambda issue and a few other things, but will get to this as soon as I can.

Based on feedback from @rsmith I've been trying to get this to work with Lambdas like GCC does, though I'm quite confused about how to go about it here. It seems that the lambda definition call operator is deferred, however I'm having a hard time making sure that this happens in the "IFunc" case. I'm still working on it, but it might be a bit.

fix aaron's comments.