as somebody unfamiliar with WPD/CFI, is it necessary that they use the same llvm.type.test mechanism?

what about setting $sysroot to $sdk_path in llvm/utils/gn/build/BUILD.gn?

I'm still looking into a whole program devirtualization bug that only repros with opaque pointers, and there are still potential performance issues to look into

also no need to mention the previous revision in the final commit message

In D125847#3523502, @MatzeB wrote:

+1 to adding something to lto::Config.

Do we really need this for a temporary switch? Will this force us to keep supporting the new switch into the future for backwards compatibility in the commandline interface even when we dropped all references to typed pointers from LLVM?

I think there's some git weirdness going on, could you apply this on top of main?

In D125847#3521583, @nikic wrote:

Related bug report: https://github.com/llvm/llvm-project/issues/55377

In D125847#3521080, @MatzeB wrote:

I am not completely sure however how to deal with users specifying -Xclang -no-opaque-pointers explicitly. With this change they would end up using opaque-pointers anyway in LTO modes...

I believe the right way to do this is to add an OpaquePointers option to lto::Config, add -plugin-opt=no-opaque-pointers to LLD/LLVMgold.so, and then pass that from clang.

Alternatively we could just drop support for LTO with typed pointers :)

seems reasonable

another one :)

target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-android23"

Another crash caused by this:

for the byval case, a store can change the value loaded by a later load, so it's not completely dead in that regard

can you put the motivation in the description?

In D100780#3504820, @xbolva00 wrote:

This could be done by either exposing a simplifyLoopCFG helper function ...

This variant sounds better, if possible.

doesn't look like this has a test case for the crash, it'd be good to add one

this is causing crashes

$ cat /tmp/d.ll
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

looks like this isn't the only time this sort of thing has come up: D115927

format

(if you're interested in testing the recommit, consider running opt -O2 on the attached file)

another crash even with https://reviews.llvm.org/rGcce80bd8b74d54deb82b1b6ae0cbec1ab53c1dbb

another issue that repros at head

$ cat /tmp/a.ll
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

In D124514#3476973, @psamolysov wrote:

Change the test to use the legacy pass manager, unfortunately the buildbot doesn't accept tests with arguments for the opt tool in the following format: -passes=function(sroa),cgscc(argpromotion).

many returned analyses can't be immutable, passes can either choose to invalidate them or manually keep them up to date, making them const wouldn't allow us to keep them up to date manually

but lg anyway

In D124364#3472330, @aeubanks wrote:

would it make sense to put all of the coroutine lower passes right at the beginning of the pipeline? e.g. around LowerExpectIntrinsicPass? is there a reason CoroSplit is interleaved in the CGSCC pass manager?

I'd like to understand the constraints better before going forward with a solution that currently seems unprincipled to me

would it make sense to put all of the coroutine lower passes right at the beginning of the pipeline? e.g. around LowerExpectIntrinsicPass? is there a reason CoroSplit is interleaved in the CGSCC pass manager?

In D124360#3472326, @aeubanks wrote:

would it make sense to put all of the coroutine lower passes right at the beginning of the pipeline? e.g. around LowerExpectIntrinsicPass? is there a reason CoroSplit is interleaved in the CGSCC pass manager?

would it make sense to put all of the coroutine lower passes right at the beginning of the pipeline? e.g. around LowerExpectIntrinsicPass? is there a reason CoroSplit is interleaved in the CGSCC pass manager?

I've removed the failing opt-pipeline.ll test in 6f73bd781305266a747055875ce8352e5a36c809 since that's a legacy PM test

I'd first fix up as many in-tree users as nikic pointed out

the title should be "Remove" not "Rename"?

looks good

In D123918#3457923, @ChuanqiXu wrote:

In D123918#3457108, @MaskRay wrote:

I found there are some patches which removed legacy passes.

Yes. I have sent some after I saw nikic did for some.

An important user of us swiftshader uses createCoroCleanupLegacyPass. Would you mind giving us few days so that they can migrate away?

Of course!

Sorry for the late response, but was the buildbot fixed with https://reviews.llvm.org/rGf2d955a8a420c6866dfc9e882c8aabf33775a3fc?

take suggestion