similar to: [LLVMdev] Custom lowering DYNAMIC_STACKALLOC

On 11-06-17 10:31 AM, Sanjoy Das wrote: > Hi! > > I'm a GSoC student this year, working on implementing split stacks on LLVM. > > TL;DR: I'm facing some problems trying to get LLVM to generate the code > I want, please help me out if you can spare some time. It involves the > SelectionDAG, MachinsInstr and liveness analysis portions. > > > > I'm

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.

> Your patch looks very clean. Some comments: Heh, Jakob was faster :) > - I think you have some literal tabs in your instruction descriptions. The tabs can be seen in some other places as well. Also, there is a "mix" of coding conventions in the files. It will be really nice to use only one :) > - Your tests are nice, but you could use some more of them. I would recommend

Hi Eli, Thanks for your response. Actually, I look a lot at the ARM and THUMB1 backend implementations, and this certainly help. My architecture also have specific instructions for SP-relative accesses in a similar way than the Thumb1. During frame lowering, specific machine instructions are emitted so there’s no issue there. Also during ISelDagToDag I am able to select the right instructions.

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

On Jan 30, 2010, at 6:49 AM, Anton Korobeynikov wrote: >> Your patch looks very clean. Some comments: > Heh, Jakob was faster :) I have taken care of everything Jakob mentioned except the extra test cases. I will get to these as soon as I can. > >> - I think you have some literal tabs in your instruction descriptions. > The tabs can be seen in some other places as well.

I had been assuming that give a LiveRange a, a.valno->def, if valid, would be the same as a.start. But this is apparently not always the case. For example: Predecessors according to CFG: 0x839d130 (#3) 0x8462780 (#35) 308 %reg1051 = MOV64rr %reg1227<kill> 312 %reg1052 = MOV64rr %reg1228<kill> 316 %reg1053 = MOV64rr %reg1229<kill> 320 %reg1054 = MOV64rr

On Jan 16, 2008, at 11:49 AM, David Greene wrote: > I had been assuming that give a LiveRange a, a.valno->def, if > valid, would be the same as a.start. But this is apparently not > always the case. For example: > > Predecessors according to CFG: 0x839d130 (#3) 0x8462780 (#35) > 308 %reg1051 = MOV64rr %reg1227<kill> > 312 %reg1052 = MOV64rr %reg1228<kill>

Hello, I'm trying to understand the relationship between MachineMemOperand and, on X86, memory operands of machine instructions. The latter seem to be operands held in order by the MachineInstr, from an offset onwards - Base, Scale, Index, Displacement, Segment. The former, if I understand it correctly, is used to hold a relationship back to IR load/store instructions. Is it possible to have

Hello Mircea, > On 8 Mar 2018, at 18:52, Mircea Trofin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > I'm trying to understand the relationship between MachineMemOperand and, on X86, memory operands of machine instructions. The latter seem to be operands held in order by the MachineInstr, from an offset onwards - Base, Scale, Index, Displacement,

Thanks for the details! How should we think of the case where an instruction has memory operands (in the sense that X86II::getMemoryOperandNo >=0), but doesn't have MachineMemOperands? I'm seeing an example in the case of __builtin_prefetch (lowered via SelectionDAG::getMemIntrinsicNode, which produces a MachineMemOperand) vs __builtin_ia32_gatherpfdpd, lowered through getPrefetchNode

On Aug 26, 2010, at 12:59 PMPDT, Eric Christopher wrote: > On Aug 26, 2010, at 12:25 PM, Yuri wrote: >> On 08/26/2010 11:53, Eric Christopher wrote: >>> Could you get it to print out the instruction when it happens? >>> (just change the line above the error message to print it out to >>> errs()). >>> >>> It basically means that a pseudo

Hi LLVMers, I have finally sorted out licensing issues and found some time, so I'm trying to port my PBQP register allocator to 2.4 in order to contribute it (if you want it). I've run into a bug that has me confused though. I'm currently failing the following assertion: llc: VirtRegMap.cpp:1733: void<unnamed>::LocalSpiller::RewriteMBB(llvm::MachineBasicBlock&,

On Aug 26, 2010, at 11:34 PMPDT, Yuri wrote: > On 08/26/2010 13:17, Dale Johannesen wrote: >>>> Insn before the error: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, >>>> %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... >>> >>> Odd. I thought TCReturn was being lowered. At any rate can you >>> file a bug

Hi, I am working on a new back-end for LLVM. This architecture has two register types, data(A) and accumulator(B). A registers are i32 where as B registers are i64. This is causing me some headaches, as far as I can tell, it's not really possible to mix the two using tablegen? In the hardware, every instruction can either take an A register or a B register, in tablegen (as far as I can

On Sep 3, 2008, at 5:58 AM, Lang Hames wrote: > Hi LLVMers, > > I have finally sorted out licensing issues and found some time, so I'm > trying to port my PBQP register allocator to 2.4 in order to Nice! We would definitely welcome your contribution. > > contribute it (if you want it). I've run into a bug that has me > confused though. > > I'm currently

On 08/26/2010 13:17, Dale Johannesen wrote: >>> Insn before the error: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, >>> %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... >> >> Odd. I thought TCReturn was being lowered. At any rate can you file >> a bug with the .ll file that causes this? > > It should be getting

On Tue, Jul 28, 2015 at 6:34 PM, Reid Kleckner <rnk at google.com> wrote: > On Tue, Jul 28, 2015 at 2:25 AM, John Kåre Alsaker > <john.mailinglists at gmail.com> wrote: >> >> On Tue, Jul 28, 2015 at 12:44 AM, Reid Kleckner <rnk at google.com> wrote: >> > Yeah, the function attributes section of LangRef is a reasonable place >> > to >>

Hi, In GCC there is one useful option -dp (or -dP for more verbose output) to annotate assembler with instruction patterns, that was used when assembler was generated. For example: double test(long long s) { return s; } gcc -S -dp -O0 test.c test: .LFB0: .cfi_startproc pushq %rbp # 18 *pushdi2_rex64/1 [length = 1] .cfi_def_cfa_offset 16 movq %rsp, %rbp # 19 *movdi_1_rex64/2

I started to implement inlining of the stack probe function based on Microsoft's inlined stack probes in https://github.com/Microsoft/llvm/tree/MS. Do we know why the stack pointer cannot be updated in a loop (which results in ideal code)? I noticed that was commented in Microsoft's code. I suspect this is due to debug or unwinding information, since it is allowed on Windows x86-32. I