@lebedev.ri Thanks! No, I haven't filed the issue yet. The current blocking issue is that I see the regression when compiled with JIT, but not with opt. I think I need to figure out the exact set of flags I need to give opt to give me the desired behavior.

@ABataev Thanks for looking into this! You are right: when I try the opt tool I also get the same result. Yet somehow when inside TensorFlow, rolling back this revision does fix the miscompile.
Do you think you could give any advice what I can do to narrow it down? Maybe places to print before and after in vectorization passes?

Even if it is not a real cause of the problem?

The problem here that this patch does not introduce new vectorization, instead it just triggers the existing vetorization for more cases. If there is a bug in the vectorizer, this patch just allows to reveal it, not introduces it.

I find this instruction suspicious: https://gist.github.com/cheshire/bf1047b4385bcf82c22a70f5cf1fb5df#file-bad_input_ir_opt-L29

I did manage to reduce the test case further.

Runnable reproducer requires some prerequisites. It would be good if you could provide a simpler one.

@ABataev Please check out the runnable reproducer above. It clearly demonstrates a miscompile: if the pass is correct, same IR input should give identical output (barring undefined behavior, but we use sanitizers to check for that).

I've narrowed the bug down to a ptxas miscompile, the change this revision introduces is indeed benign, but it triggers a ptxas in a bad way.

@lebedev.ri Thanks for responding! I didn't intend to mail it just yet before narrowing the problem down, and realized too late just saving the revision would add the subscribers. I'll get back once I'll be able to pinpoint the problem better, it's entirely possible that your commit exposes the bug either in llvm->ptx translation (then I would be able to fix it) or the ptx emitted triggers a ptxas bug with gives bad ptx->SASS lowering.

If you're reasonable sure this is miscompiling, definitely revert. Help narrowing it down would be appreciated though.

Would you be OK speculatively reverting this change?

High-level feedback: mixing of abstraction levels is wrong for the "bundled" documentation. This might also work better as a blogpost, if you want to jump from topic to topic.

LGTM, but one of the code owners would need to sign of.
The benefit is not creating the temporary object, right?

There is at least one other conflicting commit rL353465 on top of this code already.

@mikhail.ramalho could you revert then?
In general, we should not use Z3 unless it's explicitly requested.

In the long run - sure. But porting this page to Sphinx should be a separate commit anyway.

I don't particularly care either way.
@alexandre.isoard any remaining concerns?

The change makes sense to me: seems https://github.com/llvm/llvm-project/commit/7764a04af007eca68eafcf5caaea560ed05e35a9 was not correct and a proper fix was to use avoid crashing using ASAN_OPTIONS instead.

After this landed, options for RetainCountChecker stopped working - e.g. I can't use osx.cocoa.RetainCount:blah=X.
Do you know why is this the case / how to fix it?