On Mon, Jul 13, 2026 at 11:41 PM H.J. Lu <[email protected]> wrote: > > On Mon, Jul 13, 2026 at 5:06 PM Richard Biener <[email protected]> wrote: > > > > On Sat, 11 Jul 2026, H.J. Lu wrote: > > > > > commit e754b70fe5470b975d31887fa5647f1c92d6522d > > > Author: H.J. Lu <[email protected]> > > > Date: Tue Apr 7 23:16:38 2026 +0800 > > > > > > x86: Rewrite ix86_find_max_used_stack_alignment > > > > > > doesn't handle > > > > > > (insn 13 12 14 2 (set (reg:DI 0 ax [orig:112 _35 ] [112]) > > > (sign_extend:DI (mem/c:SI (symbol_ref:DI > > > ("vpx_quantize_b_avx_index") [flags 0x2] <var_decl 0x7fffe941f000 > > > vpx_quantize_b_avx_index>) [2 vpx_quantize_b_avx_index+0 S4 A32]))) > > > "z.c":14:56 188 {*extendsidi2_rex64} > > > (nil)) > > > ... > > > (insn 21 20 35 4 (set (mem:V4DI (reg/f:DI 0 ax [orig:104 _38 ] [104]) > > > [1 MEM[(__m256i *)_38]+0 S32 A256]) > > > (reg:V4DI 20 xmm0 [116])) "z.c":5:59 2459 {movv4di_internal} > > > (nil)) > > > > > > correctly since it assumes that > > > > > > (mem:V4DI (reg/f:DI 0 ax [orig:104 _38 ] [104]) [1 MEM[(__m256i > > > *)_38]+0 S32 A256]) > > > > > > is on stack. > > > > What do you mean by "correctly"? It is conservatively correct > > to assume "on stack". It seems we still assert that somehow > > early analysis (during expand) matches up with late IL analysis > > (wherever) in "optimality"? We cannot do such thing. What > > is (should be) guaranteed is that if at RTL expansion time > > we concluded something is _not_ on stack then we should not > > be able to late _prove_ it is on stack - but all we can do > > is perform conservative assessment, meaning we have to error > > on the "on stack" side. > > > > If we can _prove_ nothing on the stack has alignment > X then > > we can possibly late lower required stack alignment. But we > > shouldn't assert that we compute a late required alignment > > of <= the original alignment, if the IL degraded we can end > > up with > original alignment, which we can disregard, doing > > nothing, since the initial computation has to be conservative > > already. > > > > Instead of again adding x86 specific "points-to hacks", please > > make sure we do not have such bogus assertions and if needed > > for optimization, improve RTL points-to analysis. > > > > Richard. > > > > I'd like to revert > > commit e754b70fe5470b975d31887fa5647f1c92d6522d > Author: H.J. Lu <[email protected]> > AuthorDate: Tue Apr 7 23:16:38 2026 +0800 > Commit: H.J. Lu <[email protected]> > CommitDate: Mon Jul 6 16:11:45 2026 +0800 > > x86: Rewrite ix86_find_max_used_stack_alignment > > and add 2 tests. We can revisit it later.
According to [1]: "... no outside approval is needed to revert a patch that you checked in." So, please just check in the revert and copy it to gcc-patches. [1] https://gcc.gnu.org/gitwrite.html#all Uros.
