On 4/8/25 12:27, Robin Dapp wrote: >>>> Yay ! It does work. Awesome. >>>> I've uploaded the further reduced test to PR/119533 >>> Hmm, I'm seeing the same ICE as before with my patch. Did you happen to >>> change >>> something else on your local tree still?
Yeah I had some debug stuff lying around. In particular it is missing the initializer for kill bitmap. @@ -2698,6 +2713,7 @@ pre_vsetvl::compute_lcm_local_properties () m_avout = sbitmap_vector_alloc (last_basic_block_for_fn (cfun), num_exprs); bitmap_vector_clear (m_avloc, last_basic_block_for_fn (cfun)); + bitmap_vector_clear (m_kill, last_basic_block_for_fn (cfun)); bitmap_vector_clear (m_antloc, last_basic_block_for_fn (cfun)); bitmap_vector_ones (m_transp, last_basic_block_for_fn (cfun)); >> On top, I'm now seeing a ton of vsetvl test failures vs just the one I >> reported... No idea what I have been testing before. Grml. >From your inline diff (with "!= 1" as cue) , I'd placed the check as follows if (!curr_info.valid_p () || eg->probability == profile_probability::never () || src_block_info.probability == profile_probability::uninitialized () /* When multiple set bits in earliest edge, such edge may have infinite loop in preds or succs or multiple conflict vsetvl expression which make such edge is unrelated. We don't perform fusion for such situation. */ || bitmap_count_bits (e) != 1) continue; + if (!bitmap_bit_p (m_transp[eg->src->index], expr_index)) + continue; With both of above changes both go tests passed in the morning. > Ah, of course the check was intended to be inside src_block_info.empty_p () > and > not outside. That gets rid of the test failures. But the go tests still ICE > for me, one way or another. Now I moved the bitmap check further down inside src_block_info.empty_p () and both tests still pass. So looks like the kill bitmap init is essential as well. -Vineet
