[LLVMdev] [PATCH] Segmented Stacks

[Rafael Ávila de Espíndola]

On 07/14/2011 12:07 PM, Sanjoy Das wrote:
> Hi llvm-dev!
>
> I have attached the current state of my GSoC work in patches [1] for
> review; this currently allows LLVM to correctly handle functions running
> out of stack space and variable sized stack objects.
>
> Firstly, since I think it is better to get things merged in small
> chunks, I'd like to have some specific feedback on where my work stands
> in terms of mergeability.

The patches look great! Just some comments:

Can you move the command line condition to addCommonCodeGenPasses 
instead of returning early from runOnMachineFunction? That should avoid 
printing the pass with -debug-pass=Arguments if it is not used for example.

runOnMachineFunction only needs to return true if changes were made. 
Maybe adjustForSegmentedStacks should return a bool.

It might be a good idea to add a comment that the particular stack size 
checks sequences are important as the linker patter matches them.

A micro optimization in EmitLoweredSegAlloca: can you reused the sub if 
we find out that we have enough stack space?

+  if (!Is64Bit)
+    BuildMI(mallocMBB, DL, TII->get(X86::SUB32ri), 
physSPReg).addReg(physSPReg)
+      .addImm(16);

You can merge this if with the else just before it.

In the test:

+; Just to prevent the alloca from being optimized away
+define void @dummy(i32* %val, i32 %len) {
+        ret void
+}
+

Probably better to just declare it.

You should use X32-NEXT: and X64-NEXT: when the instructions are 
required to be on the next line.


> Secondly, I had been working on supporting variable arguments before I
> started to clean up my work and roll a patch series. The varargs work is
> not completed yet; and I recall having a discussion on this list some
> time back [2] about adding support for co-routines. Does postponing the
> vararg work and seeing if co-routines can be implemented sound more
> useful (since we should be able to cheaply create and destroy stacks
> now). I understand that segmented stacks will primarily be used by
> managed languages; does support for varargs seem important enough in
> such cases?
 >
> Thanks!
>
> [1] I'm working on implementing segmented stacks as a part of GSoC '11.
>
> [2] The previous discussion has concluded with a suggestion of adding
> three intrinsics to LLVM: llvm.stacknew, llvm.stackswitch and
> llvm.stackdestroy; which should be enough to allow the frontend
> developer to implement his or her own co-routining semantics.

If not adding coroutines to llvm, are these intrinsics necessary? We are 
discussing implementing something like it in rust, but it would probably 
be implemented with an assembly function that saves the registers to the 
stack and jumps to the scheduler. From the caller point of view, that 
function just takes a long time return.

One advantaged I see in having them in llvm that it could have some nice 
iterations with the split stacks. For example, the space left check 
could account for space used by a possible call to stackswitch etc.

Cheers,
Rafael