For the avx tests, I don't suppose you know a simple way to generate these tests? They're about 10k lines long and it's taking a while to go through it by hand to replace the current IR checks with codegen for -O1. (Perhaps something along the lines of utils/update_llc_test_checks.py in llvm?)

I did some more digging and found the following differences between PMs for each test, and they seem to all differ and can be fixed for different reasons.

In D63153#1540920, @chandlerc wrote:

Code change LGTM. Can you update at least one of the tests to explicitly run both PMs so that we'll notice if this breaks in some weird way? Feel free to submit with that change.

In D62888#1537233, @chandlerc wrote:

I would just change this to have the module pass loop over the functions -- that seems like it'll be much cleaner.

As it is, I'm not seeing where the loop actually happens. But rather than trying to figure that out, just seems better to turn it into an explicit loop. That way you can get rid of all the check analysis overhead I think.

In D62225#1537248, @chandlerc wrote:

I think this ultimately needs to be split up into smaller patches. A bunch of these things can be landed independently. Here is my first cut at things to split out, each one into its own patch.

In D62088#1537081, @rjmccall wrote:

In D62088#1531773, @leonardchan wrote:

Well, I think the builtin has to be able to operate on signed scaled-integer / fixed-point types, and you'll have to specify the behavior for negative numbers. If you're comfortable implementing those semantics inline in the caller, then I agree you don't need signed functions in compiler-rt.

Ok. I'll add it to the caller when adding the builtin clang function. We can handle usage with different types there.

Okay. Please mention the behavior for 0 in the documentation, since this function is not otherwise defined for 0.

*ping*

Well, I think the builtin has to be able to operate on signed scaled-integer / fixed-point types, and you'll have to specify the behavior for negative numbers. If you're comfortable implementing those semantics inline in the caller, then I agree you don't need signed functions in compiler-rt.

In D62088#1523994, @saugustine wrote:

The number is the argument count plus one for return value. So this function should be named

__log10scaleddi3

In D62088#1522446, @rjmccall wrote:

I don't review compiler-rt patches generally. Can you explain what would actually use this function? Is there supposed to be a new Clang builtin for it?

For now, I made the avx512-reduceMinMaxIntrin.c test only run under the legacy PM since there were already too many changes in this patch. The changes were lit expecting allocas for temporary variables to be in specific orders which weren't respected in the new PM for some reason, but still followed the same logic. I can update this in a later patch separated from this one to make reviewing easier.

In D62225#1519394, @efriedma wrote:

Are the behavior differences between the newpm alwaysinliner and the oldpm alwaysinliner intentional? Specifically, the differences in pass remarks, and the differences in the treatment of the alwaysinline attribute seem suspect. (I'm not that interested in the different bitcasts and different order of inline allocas, although that might be nice to fix if it's a small change.)

OK, this should be all the tests and now requesting reviews. Most of the tests just require checking different output that is slightly different between pass managers whereas others were functional changes that involved adding some passes to the new PM pipeline or changing the AlwaysInliner somehow.

Hi, I'm attempting to fix all clang tests that fail when enabling the new PM by default and one of the failing tests is CodeGen/flatten.c which tests the flatten attribute. According to the docs, this attribute attempts to inline function calls in functions marked with flatten. But if I understand this patch correctly, one of the intentions is only inlining for functions and not calls.

*ping*

In D55720#1506687, @bjope wrote:

LGTM! (if all comments from other reviewers has been taken care of) (maybe you should wait another day to see if anyone else object, but I think this patch has been open for a long time so there have been plenty of time for comments already)

Btw, I'm still having a hard time reviewing the X86 test cases with very long results, and a little bit worried that those just will give annoying churn when doing unrelated patches in the future, rather than help out detecting problems related to smul.fix. I currently have no more ideas on how to improve that.

Hopefully I'll be able to run some runtime comparison tests between X86 and our OOT target when this has landed (and when I've adapted our target to use these new intrinsics using "legal" lowering and not "expand").

In D51329#1499307, @mstorsjo wrote:

This caused a regression when including mingw-w64 headers (in a case where they happen to include redundant/duplicate attribute specifications), triggering asserts. See https://bugs.llvm.org/show_bug.cgi?id=41852 for details.

Hi, it seems that this patch results in an assertion error when building zircon: