Added @hnrklssn who had worked on a similar project in the past as a reviewer.

@fhahn the changes here are a first step towards adding equivalent source expressions in compiler generated optimization analysis remarks where appropriate. In our experience, customers have found such information useful. Can you let us know your thoughts and add other reviewers that you think are appropriate? The new information is only added when the user opts-in to see the same. The generated source expressions are not perfect and we can consider making the opt-in the default as we refine and improve the implementation.

LGTM. Thanks Florian!

Thanks for the changes Florian, LGTM.

Thanks for the changes Florian. Some comments:

In D94426#2518215, @fhahn wrote:

Satish, did you see the recent changes to VPValue, which allows for easy distinction if the value is a live-in or defined in a plan? D92281 added a VPValue::getLiveInIRValue member to access live-in IR values and VPValue::getDef() can be used to check if the value is defined inside a plan. It returns nullptr for live-ins. Given that, I am not sure if the extra class provides enough benefits to justify the additional complexity?

ping

ping

LGTM.

Thanks Florian. I will request Hideki Saito to commit the change.

Added checks for the operands of OR in the predicator test.

Removed default case when checking for edge type and added a test checking generation of not and or during predication.

Thanks for the review Florian. I am addressing your comments.

In D53349#1329534, @rengolin wrote:

Right, I'm happy with the patch and will let @fhahn do the final review and approval. Thanks!

Address Renato's comments.

ping

ping

Address Florian's review comments.

I have requested Hideki Saito to submit this change on my behalf.

Addressing Robin's comment.

Florian, I have made the suggested test case changes and uploaded the same. Please take a look.

In D50820#1224411, @fhahn wrote:

LGTM with some more nits to the test cases. The EnableVPlanNativePath sprinkled around are not ideal, but I don't think there is a better alternative and we should be able to get rid of them as we go along. Please wait a few days with submitting this, to give other people a change to raise any additional concerns.

Rebased my changes.

Addressing latest comments from Florian.

Ping.

Minor formatting changes.

Addressed initial comments from Florian.

In D50820#1202465, @fhahn wrote:

Great to see this. I've left a few small comments after a first pass and will take a closer look in the next few days!

The changes look good to me. I have also verified that my outer loop vector code generation changes work with these changes after some minor modifications.

In D46827#1121624, @fhahn wrote:

Yep that sounds good. It sounds like I could update this patch to use a simplified recipe creation as Diego mentioned?

Sure, we can start with just creating the basic recipes. Should we only support widening for a start and not relying on the cost model at all? I suppose that would make things easier for outer loop code gen.