search for: dynamic_stackalloc

Hi! > Is SEG_ALLOCA marked as writing to RAX? It has RAX in its Defs list. > Is this code in github? It has been a long time since I looked at > selection dags, but I could take a look. It is up at https://github.com/sanjoy/llvm/tree/segmented-stacks > btw, have you got -view-isel-dags (and the other view dags options) > working? They are really handy for debugging this stuff.

I have a very simple kernel that exposes a bug in the backend I am working on and I cannot figure out how to fix the problem. I've narrowed down the issue to be with dynamic stack allocation. The problem I am having is that if I declare a variable inside of the loop, the code that my backend generates produces incorrect results; however, if I move this declaration outside of the loop the

...to a function that allocates the memory > from the heap [1]. The stack pointer is not modified in the second case. > > I am trying to implement this by: > > a. Custom lowering DYNAMIC_ALLOCA in case segmented stacks are enabled. > > b. Creating a X86ISD::SEG_ALLOCA node in LowerDYNAMIC_STACKALLOC if > segmented stacks are enabled. (Right now all LowerDYNAMIC_STACKALLOC on > x86 does is check for Windows and lower the call to X86ISD::WIN_ALLOCA). > > c. Having EmitLoweredSegAlloca do the checks, (calling the external > function if needed) and, in both the cases, write the poin...

...g the RSP); otherwise calling into a function that allocates the memory from the heap [1]. The stack pointer is not modified in the second case. I am trying to implement this by: a. Custom lowering DYNAMIC_ALLOCA in case segmented stacks are enabled. b. Creating a X86ISD::SEG_ALLOCA node in LowerDYNAMIC_STACKALLOC if segmented stacks are enabled. (Right now all LowerDYNAMIC_STACKALLOC on x86 does is check for Windows and lower the call to X86ISD::WIN_ALLOCA). c. Having EmitLoweredSegAlloca do the checks, (calling the external function if needed) and, in both the cases, write the pointer to the allocated mem...

Hi all! Now that LLVM has support for a larger attribute set, I think it is a good idea to add one that stops LLVM from generating segmented stacked version of a function. While implementing it, I ran into an issue: Currently, with segmented stacks enabled, LLVM sets the action for DYNAMIC_STACKALLOC to Custom, and lowers it into native X86 code. However, if a function has the nosegmentedstack attribute, DYNAMIC_STACKALLOC will need to be expanded. Is there some idiomatic way to choose whether a pseudo op is to be lowered or expanded based on some function attribute? Thanks! -- Sanjoy Das ht...

...TypeMap = cast<Constant>(I.getArgOperand(1)); * FrameIndexSDNode *FI = cast<FrameIndexSDNode>(getValue(Alloca).getNode());* GFI->addStackRoot(FI->getIndex(), TypeMap); } *return* 0; Specifically, the cast from SDNode to FrameIndexSDNode fails because the node type is DYNAMIC_STACKALLOC, while this code is expecting the node type to be "FrameIndex" or "TargetFrameIndex". (I don't know what either of these mean, I'm just telling you what the debugger is telling me.) Here's what the IR looks like: %gc_root = alloca %tart.collections.KeyError*, ali...

...mented stacked > version of a function. why? If some functions have segmented stacks, don't all functions called by it need segmented stacks too? Ciao, Duncan. While implementing it, I ran into an issue: > > Currently, with segmented stacks enabled, LLVM sets the action for > DYNAMIC_STACKALLOC to Custom, and lowers it into native X86 code. > However, if a function has the nosegmentedstack attribute, > DYNAMIC_STACKALLOC will need to be expanded. Is there some idiomatic > way to choose whether a pseudo op is to be lowered or expanded based > on some function attribute? > &...

...etArgOperand(1)); > * FrameIndexSDNode *FI = cast<FrameIndexSDNode>(getValue(Alloca).getNode());* GFI->addStackRoot(FI->getIndex(), TypeMap); > } > *return* 0; > > Specifically, the cast from SDNode to FrameIndexSDNode fails because the > node type is DYNAMIC_STACKALLOC, while this code is expecting the node type > to be "FrameIndex" or "TargetFrameIndex". (I don't know what either of these > mean, I'm just telling you what the debugger is telling me.) > > Here's what the IR looks like: > > %gc_root = alloca %tar...

...in between. Is there a better option? Thanks, Diana [1] http://reviews.llvm.org/D20156 [2] http://reviews.llvm.org/D20202 - Note that this isn't really a review yet, I just thought it looks better there than as a plain attachment. [3] LLVM :: CodeGen/AMDGPU/call.ll LLVM :: CodeGen/AMDGPU/dynamic_stackalloc.ll LLVM :: CodeGen/AMDGPU/no-hsa-graphics-shaders.ll LLVM :: CodeGen/AMDGPU/private-memory-broken.ll LLVM :: CodeGen/AMDGPU/promote-alloca-bitcast-function.ll LLVM :: CodeGen/ARM/2012-09-25-InlineAsmScalarToVectorConv2.ll LLVM :: CodeGen/BPF/many_args1.ll LLVM :: CodeGen/BPF...

...case ISD::EH_SJLJ_SETJMP: return LowerEH_SJLJ_SETJMP(Op, DAG, *this); + case ISD::EH_SJLJ_LONGJMP: return LowerEH_SJLJ_LONGJMP(Op, DAG, *this); case ISD::VASTART: return LowerVASTART(Op, DAG, *this); case ISD::VAARG: return LowerVAARG(Op, DAG); case ISD::DYNAMIC_STACKALLOC: return LowerDYNAMIC_STACKALLOC(Op, DAG, *************** *** 3052,3057 **** --- 3073,3085 ---- case SP::SELECT_CC_DFP_FCC: case SP::SELECT_CC_QFP_FCC: return expandSelectCC(MI, BB, SP::FBCOND); + case SP::EH_SJLJ_SETJMP32ri: + case SP::EH_SJLJ_SETJMP32rr: + return emitEHSjLjSe...