[llvm] [SPARC] Allow overaligned `alloca`s (PR #107223)
via llvm-commits
llvm-commits at lists.llvm.org
Tue Oct 1 19:08:06 PDT 2024
chefmax7 wrote:
> > ```
> > Assertion failed: q == top, file /vol/llvm/src/llvm-project/local/compiler-rt/test/asan/TestCases/alloca_vla_interact.cpp, line 45
> > ```
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Linux/sparc64 is worse, but AFAICS none of the failures there are related to this patch, just Linux/sparc64 specific issues.
> > Thanks again!
>
> I admit I still find it hard to understand what is this testing, so may I ask for some explaination? I'm not very familiar with the constructs used there, and, particularly, the asan functions...
Hi, sorry for the late response, I took some time for me to restore my GH account...
I don't remember all the details, but from what I remember, when implementing VLA/alloca poisoning, LLVM showed different behavior for allocation slots management between VLAs/allocas into loop nest:
* for **VLA**, I saw its stack slot being reused between loop iterations (i.e. each VLA's alloca was preceded by `@llvm.stacksave.p0()` all and followed by corresponding `@llvm.stackrestore.p0(...)`.
* for **alloca** I saw LLVM allocating a new stack slot on each loop iteration (no reuse).
So the test case was indented to check that ASAN can handle poisoning/unpoisoning correctly in presence of both VLAs/allocas into same loop nest.
However, looking on freshly generated LLVM IR, it seems this difference is not the case anymore, maybe it was a bug in LLVM back then...
That said, I think this test case doesn't have value anymore (and maybe it's even invalid now).
I'm sorry that I can't provide more technical details now, this patch is pretty old...
https://github.com/llvm/llvm-project/pull/107223
More information about the llvm-commits
mailing list