[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