I think this patch might be causing some test failures on our mac bots:

In D57836#1641679, @bjope wrote:

I'll try to finish the work on this patch (hence the commandeer action). I hope @leonardchan won't mind that.

Thanks for taking care of this! Sorry for not doing this earlier. Got caught up in other stuff.

In D44672#1637984, @vsk wrote:

In D44672#1637891, @leonardchan wrote:

It seems that this test leads to an UNREACHABLE under the new pass manager (can check this by adding -fexperimental-new-pass-manager to the test. I think this is because the passes for lowering the llvm.coro intrinsics are not yet ported to the new PM. Would it be fine to add -fno-experimental-new-pass-manager to the test to indicate it should be run under the legacy PM only? Thanks.

Sounds reasonable to me. It would be great to include a link to some master PR for the new PM porting effort with the test change.

As of now, from running check-llvm and check-clang there's 2 failing tests, but I'm trying to get those addressed.

It seems that this test leads to an UNREACHABLE under the new pass manager (can check this by adding -fexperimental-new-pass-manager to the test. I think this is because the passes for lowering the llvm.coro intrinsics are not yet ported to the new PM. Would it be fine to add -fno-experimental-new-pass-manager to the test to indicate it should be run under the legacy PM only? Thanks.

Could you temporarily revert this in the meantime? This is blocking our clang roll that we need to fix another Clang issue we're hitting.

Hi again. After some bisecting, we found that the relanding of this (rGf28e1128d9e) was causing a segfault on our aarch64 asan bots.

I think this is causing this error on our mac builders:

I believe this patch is causing 2 test failures on our x64 clang bots:

This test seems to be failing on our mac builders:

I have a suspicion that this might be causing the assertion error we see in https://bugs.llvm.org/show_bug.cgi?id=43015. Checking this now. Just wanted to raise awareness in the meantime.

Let me know if there's anything that you need from me to help diagnose this.

In D66189#1632318, @hctim wrote:

In D66189#1632302, @leonardchan wrote:

Hi. We believe this patch is causing a CMake error for out toolchian build:

-- Compiler-RT supported architectures: i386
CMake Error at /b/s/w/ir/k/llvm-project/compiler-rt/lib/gwp_asan/CMakeLists.txt:111 (target_link_options):
  Unknown CMake command "target_link_options".

Could you look into this? Thanks.

Hey Leonard, that should have been fixed in rL369051. Can you apply that patch and let me know?

Hi. We believe this patch is causing a CMake error for out toolchian build:

In D64256#1626329, @xazax.hun wrote:

In D64256#1626279, @leonardchan wrote:

In D64256#1626025, @xazax.hun wrote:

In D64256#1625998, @leonardchan wrote:

Hi. I noticed in our builders that both of the warnings introduced in this patch are being diagnosed for pointers that don't use GSL at all. I'm attempting to make a small reproducer now.

Hi!

Clang now apply GSL annotations for some STL types automatically. So this is the expected behavior. Are any of those warnings unwanted/false positive with the newest Clang version? If so, please share the reproducers and I will either fix them ASAP or revert/turn off the warnings.

Thanks! I didn't know that they were applied to stl types. This could explain why the warning is raised in my case (std::string), but I don't think there's anything wrong in this example that would lead to a warning:

leonardchan@cp-snakewater:~/llvm-monorepo/llvm-build-3-master$ cat ~/misc/test.cpp
#include <string>

std::string MakeStr();
void other_func(const char *s);

void func(std::string s) {
  const char *x = MakeStr().c_str();
  other_func(x);
}
leonardchan@cp-snakewater:~/llvm-monorepo/llvm-build-3-master$ ~/llvm-monorepo/llvm-build-3-master/bin/clang++ -c ~/misc/test.cpp
/usr/local/google/home/leonardchan/misc/test.cpp:7:19: warning: object backing the pointer will be destroyed at the end of the full-expression [-Wdangling]
  const char *x = MakeStr().c_str();
                  ^~~~~~~~~
1 warning generated.

This was made using a release build from ToT clang.

Thanks for the repro! I think this is a true positive. MakeStr will create a temporary object, and c_str() will create a pointer that points into the buffer owned by the temporary object. At the end of the full expression the temporary object is destroyed and the result of c_str will dangle.

In D64256#1626025, @xazax.hun wrote:

In D64256#1625998, @leonardchan wrote:

Hi. I noticed in our builders that both of the warnings introduced in this patch are being diagnosed for pointers that don't use GSL at all. I'm attempting to make a small reproducer now.

Hi!

Clang now apply GSL annotations for some STL types automatically. So this is the expected behavior. Are any of those warnings unwanted/false positive with the newest Clang version? If so, please share the reproducers and I will either fix them ASAP or revert/turn off the warnings.

Hi. I noticed in our builders that both of the warnings introduced in this patch are being diagnosed for pointers that don't use GSL at all. I'm attempting to make a small reproducer now.

*ping* We would like to bump up the priority of this since this allows us to enable the new PM when building fuchsia.

LGTM but I'd wait a day to see if anyone else has comments they'd like to add before landing.

Replaced with D65110

*ping*

I created D65110 if we're ok with just using the new PM.

cc: @fedor.sergeev @philip.pfaffe on this

*ping*

*ping* Is it ok to proceed with only checking the new PM output for these tests? If so I could just edit my previous patch to remove the legacy PM run lines since they already include the bitcasts from the new PM.

In D63638#1574927, @craig.topper wrote:

What if we just only check the output from the new pass manager. I don't think I care about the differences between the two.

LGTM. Good catch

In D63638#1574373, @craig.topper wrote:

There's some inliner running because the intrinsics are implemented as always_inline functions and they are clearly being inlined in -O0. In a previous post, Chandler said the new PM has a special inliner for always_inline in -O0 and the old pass manager just used the normal inliner.

In D63638#1560991, @craig.topper wrote:

In D63638#1560846, @spatel wrote:

I skimmed D63174 but haven't applied either of these patches to test locally, so I may not have the full picture.

IMO, we do not want clang regression tests running -instcombine/-instsimplify. That can cause clang tests to break when an underlying LLVM change is made. Forcing LLVM devs to depend on clang and fix the resulting breakage is backwards and unexpected extra work. This has happened to me several times.

As a compromise to the -O0 IR explosion, we do have precedent for running the optimizer's -mem2reg pass since that doesn't change frequently at this point.

And I haven't tried this, but we do have utils/update_cc_test_checks.py - this is supposed to take the manual labor out of generating assertions in the same way that we do in the optimizer and codegen regression tests with utils/update_test_checks.py and utils/update_llc_test_checks.py. Can you start with that and remove the irrelevant CHECK lines, so only the common/important lines remain? Or just use independent FileCheck '--check-prefixes'?

I definitely agree running -instcombine would be bad since it can replace squences with other sequences. -instsimplify is a little less scary because our intrinsic tests shouldn't really have a lot of things that are trivially reducible. Though that may not be as true as I want it to be. The main issue we seemed to need -instsimplify for with the new pass manager is to merge redundant bitcasts. The inliner in the old pass manager seemed to do that itself, but the new pass manager's always inliner doesn't.

*ping* @chandlerc

ping @chandlerc

Reverted in r364692

Understood. I'll revert this patch.

I mean, I'm happy for the patch to be reverted, but I still really don't understand why this fixes the test to work *exactly* the same as w/ the old pass manager and doesn't break any other tests if it is completely wrong? It seems like there must be something strange with the test coverage if this is so far off of correct without any failures...

I also don't understand what fix you are suggesting instead, but maybe you can show a patch?

In D63155#1563229, @xur wrote:

This patch does not make sense to me.

The reason of failing with -fexperimental-new-pass-manager is because we don't do PGO instrumentation at -O0. This is due to the fact that PGO instrumentation/use passes are under PassBuilder::buildPerModuleDefaultPipeline.

This patch add a pass

MPM.addPass(PGOInstrumentationGenCreateVar(PGOOpt->ProfileFile));

which only gives you the wrong signal of instrumentation is done.

I wrote pass PGOInstrumentationGenCreateVar only for some trick interactions for thinlto under ldd for CSPGO.
Regular FDO should not use it.

The right fix is to enable PGO instrumentation and use in pass builder for O0.

I would like to request to revert this patch.

@t.p.northover Would you feel ok reviewing this?

Any updates on this? I'm thinking that in the meantime maybe we could commit D63174 and work on this while that lands. If so, we could get an upstream new PM buildbot that can catch any new PM regressions.

Hmm is there usually a protocol/etiquette for getting a new built-in submitted to compiler-rt?

Is there not a function for that already in compiler-rt? Or is the problem that it doesn't necessarily exist, e.g. if we're supporting a 64-bit scaled integer type but not a 128-bit integer type?

In D63174#1553096, @craig.topper wrote:

I'm going to try to work on the X86 tests. Can we hold off on committing those?

In D63626#1553054, @chandlerc wrote:

See inline comment, but I think we should just drop the testing of the function attribute bit here rather than adjusting the pipeline.