@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.
May 26 2020
Feb 14 2020
Feb 10 2020
@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?
Feb 7 2020
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).
Feb 6 2020
Jan 31 2020
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.
Jan 30 2020
Dec 23 2019
Dec 12 2019
Nov 20 2019
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?
Oct 29 2019
Aug 15 2019
Feb 18 2019
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.
Feb 17 2019
LGTM, but one of the code owners would need to sign of.
The benefit is not creating the temporary object, right?
Feb 8 2019
There is at least one other conflicting commit rL353465 on top of this code already.
Feb 7 2019
@mikhail.ramalho could you revert then?
In general, we should not use Z3 unless it's explicitly requested.
Feb 5 2019
In the long run - sure. But porting this page to Sphinx should be a separate commit anyway.
Feb 4 2019
I don't particularly care either way.
@alexandre.isoard any remaining concerns?
Feb 1 2019
Jan 31 2019
Jan 30 2019
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.
Jan 29 2019
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?