With regards to the performance concerns - I will keep an eye on the fuzzer statistics and revert the change if the slowdown becomes too much,

Thanks for the comments! Added parseAndVerify function.

Hi. Any comments on this?

Hi. Slight ping on this?

Hi. Any comments here?

Hi. Any comments on this?

Didn't know that, thanks. Please see the updated diff.

Yes, we can. I guess it's a question of wether or not we want to optimize lib calls with the wrong integer widths. I'm seeing that we cast pointers and merely continued this approach. However I don't know this area good enough to have any solid opinion here. Any suggestions?

Slight ping? This change is not overly important but seems reasonable to me.

Note: This was reintroduced in the rL320568.

Note: This was reintroduced in the rL320568.

Note: this was reverted due to the OpenGL mesa tests failures (rL320466)

Note: this was reverted due to the OpenGL mesa tests failures (rL320466)

Hi Justin, I updated the diff to bail on all TerminatorInsts. I agree that it's better to be more general here.

Hi Sanjay, since D40650 is submitted, is this good to go?

Add constant folding.
This breaks InstSimplify/pr28725.ll. However it's now folded into constant expression and instcombine simplifies it fully. Added relevant test case to the instcombine.

I had run CTMarks and I see total compile time slowdown of about 5% with various benchmarks regressed up to 10%. This does seem a lot especially considering unclear benefit from this change. I need to figure out better approach here.

Updated with reduced test case

Thanks! Please see updated change with this issue fixed.

Hi Sanjay,

No, I haven't. I wouldn't expect big compile time impact, but I will run CTMark to be sure.

I must have confused something when doing reduction. Will update tests. Thanks.

No, unfortunately your patch doesn't fix the problem. I believe those are two different paths in the code.

Seems like I can't make tests any smaller because they need to trigger specific patterns in the instcombine

I see your point. Unfortunately I can't find any good place to common this out. Problem is that code is structured as a consecutive matching of unrelated patterns which may sometimes contain invalid shift operations. But I don't know the code base enough so maybe I'm missing something. Any advice?

Update test case

Thanks, this way is a lot better. Updated the diff.

Hi Sanjay, thanks for the comments.

Add test case

In D39555#924678, @kcc wrote:

First trophy:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4210
Looks real. Did you see it?

Hi Kostya,

Added separate function to parse exec encoded options. It's almost direct copy of the backend variant, but I hope to refactor it in a follow up changes.

Justin, I must have missed your comments in the email. I added documentation and replied inline.

Thanks for the comments. I updated the patch to support embedded "instcombine" option.

FYI, there is another issue with this change, which is filed in https://bugs.llvm.org/show_bug.cgi?id=34965

I had removed confusing merging logic. It was there only to assist with possible improvements of the mod ref info during execution of the 'getModRefInfo' function. But since there are no known examples of when this is valuable, adding extra complexity doesn't worth it.

@dberlin
A: Sorry, I should have mentioned that this change depends the alias analysis change: https://reviews.llvm.org/D29989
B: Yes, this function specifically checks for memory modifications, so it shouldn't be used to determine if store is dead.

ping?

Ok, somehow I missed this condition, please ignore this change :)

Store cache inside of the ScalarEvolution pass.