Updated the patch to use iterators instead of pointers.
No need to review since Mehdi looked and approved already.

Instead of storing pointers in the vector as you suggested, I think it will be better to store iterators. See the code snippet below.
This approach better fits C++ style. For example, this will guarantee that if operator -> for type pointer to MapEntryTy will be overloaded, it will not affect the logic of the code.
What do you think? If you agree, I will submit a new revision with these changes.

I accidentally deleted a couple of important lines in previous patch. Please ignore it and look at the latest patch only.

Updated the code to fix code review comments.

Good catch, thank you Craig! Did you know that you can reduce LLVM IR better than Delta? :)
Delta reduced the testcase quite well, but failed to remove this function.

Fixed code review comments from Steven Wu.

Updated this patch to address Steven Wu's comments:

Peter suggested that someone from Apple should have a look. I added Steven Wu as a reviewer.
Steven, could you (or someone else responsible for ld64 or ThinLTO) review and approve?

kromanova committed r325303: Allow 0 to be a valid value pruning interval in C LTO API.

Doug Yung (the reviewer for this patch) noticed that some lines exceed 80 characters limitation. I fixed that.

Teresa said that Peter Collingbourne might be the code owner for C LTO API, so I'm including him as a reviewer for this code review as well. This review was sitting for a while. Peter, could you please have a look and approve if everything looks OK to you.

Teresa said that Peter Collingbourne might be the code owner for C LTO API, so I'm including him as a reviewer. This patch was sitting for a while. Peter, could you please have a look and approve if everything looks OK to you.

Great! Teresa, please let me know if it's OK to commit or if you want me to change something in this patch.
I got an OK from Steven Wu, Apple's ThinLTO/ld64 developer.

I am definitely not against the change. It would be good to have the number means the same thing in C/C++ API. I think ld64 can be updated in advance before we release 7.0 so we can have a larger compatibility window so I don't think this should be a blocker.

Adding Apple's developers to the list of subscribers, since this patch is related to C LTO API .

In D42267#999581, @steven_wu wrote:

This indeed affects how ld64 interact with libLTO. If user didn't specify a value, ld64 will always call thinlto_codegen_set_cache_pruning_interval with interval 0. This is currently a no-op so it will use whatever the default value in libLTO. With this change, it will be force pruning.

It is possible for us to make change to future ld64 to use different value but it is not going work very well for compatibility. If old ld64 loaded a new libLTO, it is going to lose incremental build.

Please let me know if more changes needed to this patch.

In D42267#992799, @tejohnson wrote:

It looks ok to me, but I am not sure how ld64 is using this - are they also setting to 0 by default expecting default behavior?

We have a request for this feature in clang-format in Sony.

Addressed code review comments.

Hello,
Will it possible to review this patch also? Thank you so much in advance.
Does someone knows who in Apple is responsible for ThinLTO? It might be helpful to add this person as a reviewer.
Katya.

Hello,
Will it possible to review this patch? Thank you so much in advance.
Katya.

In D41523#968776, @craig.topper wrote:

The builtins are tested in tests like test/CodeGen/sse-builtins.c,

LGTM too.

In D41523#968359, @RKSimon wrote:

Sort of related - should we enable -Wdocumentation (it's currently -Wall and -Weverything might be too much....) on the respective clang builtin tests? Doesn't have to be part of this patch.

Thank you for the review, David! I have changed debug line version to V4, when DWARF V5 is requested (this is just a temporary measure until debug line V5 is supported).

This was for information purpose only (by Sean Silva's request) and no review was needed. All doxygen comments for x86 intrinsic had already landed, so I am abandoning this review.

Changed the instruction name from VMOVSD to VMOVQ for _mm_loadu_si64

I have committed this patch today r285355 and have to revert it shortly in r285362, because some tests were failing.