https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
--- Comment #20 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 30 Jan 2024, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059 > > --- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #17) > > (In reply to Jakub Jelinek from comment #16) > > > The question is revert what exactly? > > > If we revert r14-6210, we get back the other P1. Or do you mean revert > > > r14-5355? > > > I guess another option is move the vzeroupper pass one pass later, i.e. > > > after pass_gcse. > > > > I think moving mdreorg passes as late as possible esp. when they don't play > > well with DF/notes is a good thing. Maybe even after pass_rtl_dse2 and > > thus after shrink-wrapping? > > The thing is that the vzeroupper pass actually plays well with DF notes, the > problem is that it now (in GCC 14) asks for them to be computed. > The first issue was that vzeroupper before postreload_cse computed the notes, > then > postreload_cse CSEd something and made the REG_UNUSED invalid without killing > them and then later passes went wrong because of the incorrect notes. > This issue is that vzeroupper now after postreload_cse but before gcse2 > computes notes, then gcse2 CSEs something and makes REG_UNUSED invalid, rest > is > the same. > But, I believe gcse2 is the last CSE-ish pass. > I wouldn't move it too much further, because I don't remember the interactions > between vzeroupper, splitting and peepholes. OK, so the "real" revert would then simply kill the notes actively again after vzeroupper? Btw, DSE also uses cselib, but I'm not sure whether it uses REG_UNUSED but IIRC it does "redundant store" removal and it does replace reads in some cases ... (not sure if after reload though). So for maximum safety if we'd have a way to kill off REG_UNUSED maybe we should do that instead? OTOH any "stray" valid REG_UNUSED notes not causing issues with gcse or postreload_cse might not be preserved and cause missed optimizations later ...
