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.
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.
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
+}
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.
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?
I think I was the one who was interested in support for coroutines. My language doesn’t currently use variable arguments, but there might be others who would find it useful.
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.
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?
I think I was the one who was interested in support for coroutines. My language doesn’t currently use variable arguments, but there might be others who would find it useful.
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.
Actually, now that I think of it there’s something I need that is of higher priority (for me anyway) than either of the things you mention: Will I still be able to iterate through stack frames for purposes of garbage collection? In other words, if I use the segmented stack feature, will I need to modify my code that traces roots on the stack?