My first version was without "2>&1", still doesn't show the content of the redirected output for some reason.

I have troubles making it work... I'm adding truncate.txt next to Inputs/shtest-output-printing/basic.txt with content like this:

I forgot to ask earlier: is there no test case for this feature?

My use-case is downstream where I use FileCheck against stderr like this:

Ping x2. Can you suggest who can I ask to review this?

Ping.

Thanks!

LGTM other than a minor nit.

ping.

Rebase + ping

Ping

Rebase

Address Erich's comments

Hi guys, do you want me to fix anything else? I think I've addressed what I could.

Fix a bug with not saving builder's insertion point.

Remove stale FIXME comment in the code being moved

Apply reviewers' suggestions. Thanks!

Another version. My main goal here is to gradually move more stuff from clang/
to llvm/ so I'm open to other suggestions in doing so.

The main alternative I see here is to use different logic for opaque pointers and always base them off an i8 element type

Currently I am not sure how to best write a CHECK-line that will fail if a new successor gets added, e.g. CHECK: Successor(s): if.then.0 will also pass if an additional successor gets added. Perhaps we should just include the number of successors, something like 1 Successor: if.then, or 3 Successors: a, b, c.

Looks good to me. Thanks for following up on that.

IIUC we will have non-recipe users in the future (e.g. live-outs)

LGTM.

LGTM, thanks!

VPlan part looks good to me. I'm not familiar with implementation details of the filtered_iterator to discuss the to_reference->filter->to_pointer approach though. Regardless of that, it's an improvement in interfaces, so LGTM unless someone has a way to make filtering work with pointer directly.

LGTM, thanks!

I think it's functionally correct now, just have a few suggestions to simplify the code a little bit.

LGTM, please wait a day or two to let others take a look.

It seems the code wasn't properly guarded before this change, and the proper fix would require changing too many places. I'd prefer to do it in separate patch.

Sorry for the troubles and thanks for reverting that for me - I didn't receive notifications from buildbots for it. Yes, it's probably related to those #ifs. I'm starting a Release build to reproduce and create a fix.

Address review comments.

• Improve comments.
• Don't add a new dump point via cl::opt. Instead, add cl::opt to toggle behavior (dot/plain dumps) for the LVP::printPlans method.

Ping.

I didn't recognize that it's still WIP until some point, so some nitpicking comments aren't very useful probably...

Rebased on top of D97787.

Ping

Move common implementation of get/set methods into helpers

Not blocking this review, but I think it's bug-prone to mix lane 0 of scalarized divergent values and truly uniform values that can be kept on a single scalar. Possible examples:

Hi Florian, I'm starting to familiarize myself with VPlan and wonder if that is a short/mid-term solution or something that is expected to be a long-term.

Ping. I don't see any comments that require action on my side.

In D72740#1822003, @RKSimon wrote:

This (and D72739) should be in 10.0 - please can you raise a bug and block https://bugs.llvm.org/show_bug.cgi?id=44555

Remove target datalayout string from the test