Address refactor comments.

Thanks, River! Some comments inline.
I think I can refactor some of the code in the patterns but I'd like to know if there is any major concern with this approach before moving forward.

Thanks River! I'll commit this in a while if no more comments.

Thanks, Ayal! LGTM

Not needed for now

Not needed for now.

Thanks, @plotfi. Sorry about that. It passed with gcc in my local machine. I'll check with Clang.

Thanks for the quick response, Lang! I'll proceed with the commit in a while, in case somebody else has any comments.

LGTM! Thanks, Francesco!

Or are you saying this needs to be done explicitly for stress testing?

In D59952#1447695, @fpetrogalli wrote:

In D59952#1447146, @dcaballe wrote:

Should we add a small lit test that covers the new expected behavior? Probably reusing one from D57598 with the stress testing flag would suffice.

Good idea. Something that invokes stress testing and sets VF = 4 when the computed VF is 1. Did I get it right?

Should we add a small lit test that covers the new expected behavior? Probably reusing one from D57598 with the stress testing flag would suffice.

I thought the point was to just have a VF to build a VPlan with and as it currently stands we build the same VPlans with VF = 4 or any other VF I think. With the programmatically determined VF, we would be a little closer to reality in the stress testing. As Hideki mentioned, having a constant factor for stress testing might have other benefits later on though

Yep, I agree on that we should keep the stress testing mechanism. It will be very useful to make sure that the construction and predication (and maybe other transformation) are robust enough since we can run it on loop nests that are not necessarily vectorizable.
Something important, though, is that we shouldn't use this mechanism to bypass legality or pragma simd requirements to vectorize a loop, i.e., we shouldn't use it to generate actual vector code.
What are you trying to achieve, Francesco?

Thanks, Francesco. LGTM!

LGTM (as you could see in my previous message :))

Thanks Francesco for helping us remove some of the constraints we have in VPlan native path!
I agree with the idea of using getSmallestAndWidestTypes() as a starting point whereas we don't have the proper cost model.

Hey Florian! Thanks a lot for taking care of this! I'm leaving a comment below. Please, let me know what you think.

Hi Florian,

From the VPlan point of view, LGTM. I don't have any other comments.

LGTM!

In case you missed it, there is some discussion in D50480 regarding this code. Your feedback would be appreciated.

Reverted to use the original ICmpULE extended opcode instead of detached ICmpInst. This can be revised quite easily once VPInstructions acquire any other form of modeling compares.

Thanks, Ayal! Some comments below.
Do you see any potential issue that could make modeling this in the VPlan native path complicated once we have predication?

Just a few comments.

Thanks for working on this, Florian, and sorry for my delayed response. I added some initial comments. I'll come back soon.

Thanks, Florian! I'll go ahead with the commit!

Thanks for the review, Florian!
I'll commit this once D48815 is approved and committed.

Making VPLoopInfo object a member of VPlan.

Reverting GraphTraits changes and adding VPlanTestBase as friend of VPlanHCFGBuilder.

Thanks for the comments, Florian! Addressing your comments.

Rebasing this patch on top of D49032

Rebasing this patch on top of D49032.

Rebasing this patch on top of D49032.

Addressing Chandler's comments. Thanks, Chandler!
Yes, I have commit access.

Good idea! Thanks! LGTM. Just some minor comments.

Thanks, Florian! I'll commit next week.

Thanks a lot, Florian! LGTM!

Hi Robert,