Too many variables are created in some cases

[antoyo]

Like in this case before this fix.

[FractalFir]

Do you have any concrete examples of this ?

I think this is related to the huge stack usage we see when building rustc, but a smaller example would be better.

[antoyo]

There was an AVX-512 test in stdarch that would do a stack overflow. I don't remember exactly which one, but I have talked a bit about this in this blog article.

If you revert this fix, you should be able to reproduce it.

However, I'm not sure that's related to the stack usage issue you have when building rustc because this issue is about stack usage in the resulting program.
Or maybe it is since in your case the resulting program is rustc?
Do you know which function uses a lot of stack space?
If so, you could try looking at the GIMPLE output for this function to get an idea of what's going on.

[FractalFir]

It was a stack overflow in `libgccjit`, where a function responsible for validating a tree reached 18 K levels of recursion. That, to me, seems to suggest wee are generating some rather chunky trees.

…

On Mon, May 26, 2025, 00:46 antoyo ***@***.***> wrote: *antoyo* left a comment (rust-lang/rustc_codegen_gcc#611) <#611 (comment)> There was an AVX-512 test in stdarch that would do a stack overflow. I don't remember exactly which one, but I have talked a bit about this in this blog article <https://blog.antoyo.xyz/development-rustc_codegen_gcc-2#avx_512_tests_failing> . If you revert this fix <02198d8#diff-e4f794ca308aa712cbad31feb714df7cada1bbe453a30e232e45891571430263R1910-R1917>, you should be able to reproduce it. However, I'm not sure that's related to the stack usage issue you have when building rustc because this issue is about stack usage in the resulting program. Or maybe it is since in your case the resulting program is rustc? Do you know which function uses a lot of stack space? If so, you could try looking at the GIMPLE output for this function to get an idea of what's going on. — Reply to this email directly, view it on GitHub <#611 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AR52NDSZEMS4247225QDF6D3AJB23AVCNFSM6AAAAABV6NG4HWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMBYGEZTENZUG4> . You are receiving this because you commented.Message ID: ***@***.***>

[antoyo]

Can you please tell me which function it is?
We had such a weird stack overflow in the past. Maybe it is related.

[FractalFir]

`verify_vssa`.

…

On Mon, May 26, 2025, 01:43 antoyo ***@***.***> wrote: *antoyo* left a comment (rust-lang/rustc_codegen_gcc#611) <#611 (comment)> Can you please tell me which function it is? We had such a weird stack overflow in the past. Maybe it is related. — Reply to this email directly, view it on GitHub <#611 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AR52NDQERXI34OGVQXBBEZD3AJISVAVCNFSM6AAAAABV6NG4HWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMBYGE3DGMZWHA> . You are receiving this because you commented.Message ID: ***@***.***>

[antoyo]

Ok, so this is not the function I had issues with in the past.
Don't hesitate to ask if you need help to debug this issue.

[FractalFir]

I was wrong: it is actually 37 K recursive calls to verify_vssa. It seems like those calls happen when compiling the function with symbol _RNvNtNtCsgG9CEInw1aP_17rustc_codegen_gcc9intrinsic4llvm9intrinsic (rustc_codegen_gcc::intrinsic::llvm::intrinsic).

That function is full of string constants - maybe we handle them inefficently?

[FractalFir]

This seems to just be the case of "20 K string constants in one function is a lot". All I need to replicate the crash is try to compile archs.rs.

I don't know if there is a good way to fix this long-term(in cg_gcc), but, for now, we can change the way archs.rs is generated to make it more efficent(in terms of runtime and compiletime performance).

[antoyo]

I thought verify_vssa would recurse on basic blocks (it would also make sense that the problem is a huge number of basic blocks since archs.rs contains a huge match expression).
Are you sure the problem are string constants?
Also, aren't string constants supposed to be globals?

[antoyo]

Seems like a known issue in GCC.

[FractalFir]

I did not know it recursed on blocks, I kind of guestimated what the cause could be.

Still, we have 10 K branches of the match, so this is a problem either way. I have a commit ready that splits the function into separate, per-arch sub functions.

[antoyo]

Ok, this is a good workaround for now.

Would you be interested in trying to fix the bug in GCC in the future?
If not, I'll look at it.