On 4/8/25 13:47, Vineet Gupta wrote: > 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.
Doh ! Something is weird, I did a clean everything and now I see the issues still and it seems for baseline build, prinstine trunk is hitting ICE on glibc build as of 2025-04-08 0980a6ff7ae3 Daily bump. Let me untangle my testing first. -Vineet
