Created attachment 145109 [details]
Amber test exposing the problem
catchsegv amber write-red-in-loop-nest.amber
leads to a segmentation fault, with a backtrace that ends in nir_from_ssa, e.g.:
or sometimes in ralloc.
Build: Mesa 19.2.0-devel (git-861c2b8d31) (Debug)
Device: Intel(R) HD Graphics 630 (Kaby Lake GT2)
Created attachment 145110 [details]
Another Amber test that exposes the problem
There is MR on review that fixes this issue https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1717
See https://bugs.freedesktop.org/show_bug.cgi?id=111405 and https://bugs.freedesktop.org/show_bug.cgi?id=111069
hi, bisect results lead me to:
8d8222461f9d7f497d657c2c0eff70820986429b is the first bad commit
Author: Jason Ekstrand <email@example.com>
Date: Mon Jul 23 22:20:41 2018 -0700
intel/nir: Enable nir_opt_find_array_copies
With a patch from Danylo current test becomes Passed.
[den@den-pc Debug]$ ./amber '/home/den/Downloads/write-red-in-loop-nest.amber'
Summary: 1 pass, 0 fail
I am sorry, I mixed up bisection results between issues.
Correct bisected commit is:
8fb8ebfbb05d3323481c8ba6d320b3a3580bad99 is the first bad commit
Author: Ian Romanick <firstname.lastname@example.org>
Date: Tue May 22 18:56:41 2018 -0700
intel/compiler: More peephole select
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1717 fixes this issue.
The bug is still reproducible on the latest master but now it is not "segmentation fault" it is an infinite compilation. Looks like the following patch fixes this issue (not sure that it is a good solution because I am not familiar with this part of the code):
diff --git a/src/compiler/nir/nir_repair_ssa.c b/src/compiler/nir/nir_repair_ssa.c
index 757afff490d..901aec90a07 100644
@@ -132,8 +132,9 @@ repair_ssa_def(nir_ssa_def *def, void *void_state)
block_def = &cast->dest.ssa;
- nir_instr_rewrite_src(src->parent_instr, src,
+ if(def != block_def)
+ nir_instr_rewrite_src(src->parent_instr, src,
The root cause is that we infinite remove a first element of the list 'def->uses' and add this element to the end of this list.
That's pretty much the correct patch as far as I can tell. I poked at it a bit and wrote something a bit longer which also prevents any such issues with ifs: