similar to: [LLVMdev] Is it possible to have multiple stacks in the backend?

Hi all, I understand from the document that I should be able to configure llvm with only specific targets by passing -DLLVM_TARGETS_TO_BUILD=some-backend to cmake. However, I get the following errors whenever I don't include X86 in the target list: CMake Error at cmake/modules/LLVMConfig.cmake:127 (message): Library `X86' not found in list of llvm libraries. Call Stack (most recent

On Tue, Mar 15, 2011 at 6:34 PM, Dongrui She <sarevokcc at gmail.com> wrote: > However, I get the following errors whenever I don't include X86 in the > target list: on top of trunk, it seems cmake requires at least "native" (for yours, X86) target. (I reconfirmed with -DLLVM_TARGETS_TO_BUILD=ARM on x86) For workaround, you have to include "X86" always.

Hello LLVMdev, I have been working with LLVM for just over a year now, mainly in the area of compilation for HDLs like SystemVerilog and SystemC. Most of this work dealt with translation to LLVM IR, representing concurrent languages with LLVM and using LLVM analyses and transforms for compiling onto proprietary simulation acceleration hardware. All of this work used the C back end exclusively,

Hi Nick, Nick Johnson wrote: >> I'd like to generate this layout: >> >> 12(%ebp) - second function parameter >> 8(%ebp) - first function parameter >> 4(%ebp) - old %EIP (the function's "return address") >> 0(%ebp) - old %EBP (previous function's base pointer) >> -4(%ebp) - My language specific information

Hi all, I am working on an out-of-tree target. I am wondering if it is possible to force the register allocator (and/or spiller) to not break certain instruction sequence. For example: phys_reg = MI1 vreg1 vreg 2 = MI2 phys_reg Is there a way to tell RA/spiller not to insert COPY or spill between MI1 and MI2? I am using greedy register allocator and inline spiller. -- Regards, Dongrui

Hi, Nicolas > Yes, I do :) There are some alternatives, but this looks like the most > efficient. What I'm facing is engineering issues, since adding a new > information in the stack frame is similar to adding the frame-pointer > information. I don't see any huge problems with writing such pass: just create stack frame objects at fixed offsets inside your MF pass - and

Hi, attached is a second try for the bigstack patch for SPU, with testcase. It is essentially the patch committed as 97091, and reverted as 97099, but with the following additions: -in vararg handling, registers are marked to be live, to not confuse the register scavenger -function prologue and epilogue are not emitted, if the stack size is 16. 16 means it is empty - there is only the

On Feb 26, 2009, at 2:02 PM, John Mosby wrote: > Hello LLVMdev, > > I have been working with LLVM for just over a year now, mainly in > the area of compilation for HDLs like SystemVerilog and SystemC. > Most of this work dealt with translation to LLVM IR, representing > concurrent languages with LLVM and using LLVM analyses and transforms > for compiling onto proprietary

On Mar 29, 2010, at 6:50 AM, Kalle Raiskila wrote: > attached is a second try for the bigstack patch for SPU, with testcase. It is essentially the patch committed as 97091, and reverted as 97099, but with the following additions: > -in vararg handling, registers are marked to be live, to not confuse the register scavenger Looks good. You can try running with -verify-machineinstrs to detect

Hi, I am wondering how to specify the selection DAG patterns for instructions that use accumulator. For example multiply-accumulate instruction with one destination operand and two source operands: mac $dst, $src1, $src2 ;; $dst += $src1*$src2 Seems that it has a cycle in the pattern. So how do I specify it in the DAG? There are a few instructions in the ARM backend like this one, but the

Hi all, I try to print the live-in and live-out registers for each basic block in a backend for my own target. And I can get a list of live-in registers directly in MachineBasicBlock. Is there a quick way to also get the list of live-out registers without redoing the analysis. I think this information is computed and stored somewhere. -- Regards, Dongrui -------------- next part

Hi, Have you try to directly describe such patterns in tblgen file? Like this: (brcond (i32 (cond_op RC:$rs, RC:$rt)), bb:$offset) MIPS backend does that. I also do this in my own backend, and seem to be working fine. On Mon, Jan 7, 2013 at 11:55 AM, Vikram Singh <vsp1729 at gmail.com> wrote: > I have seen that most of the targets do comparison and branching > in two separate

First, thanks very much for your comments! On Sat, Feb 28, 2009 at 8:05 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Feb 26, 2009, at 2:02 PM, John Mosby wrote: > > It is limited to X86 presently since that is the only target I have > > access to at the moment. > > What part of this is target dependent? Is this due to emitPrologue / > emitEpilogue being

Hello, Arnold. > Is there a way to indicate that the register the tail call > instruction uses as destination needs to be valid after the callee > saved registers have been restored? (some X86InstrInfo.td foo magic > maybe ?) It's wrong way to do the things. Because in this case you either violate the ABI for callee, or you're restricted to do tail call lowering only for

On Thu, Apr 15, 2010 at 3:40 AM, Artur Pietrek <pietreka at gmail.com> wrote: > Hi all > Ups, I'm really sorry for that previous message, I've sent it by mistake. > > So let me write it once more. > > I've been working for some time now on a backend for our CPU. However I > couldn't figure out how to implement some stuff. > I'd appreciate your help

Hi all, I want to implement the Xor random canary, so I have to get the return address in the prologue and epilogue of the function. In the prologue of the function, before I insert into the canary on the stack, I can get the return address by: ConstantInt* ci = llvm::ConstantInt::get(Type::getInt32Ty(RI->getContext()), 0); Value* Args1[] = {ci}; CallInst* callInst =

Hi Andrew, thanks for answering On Thu, Apr 15, 2010 at 3:35 PM, Andrew Lenharth <andrewl at lenharth.org>wrote: > On Thu, Apr 15, 2010 at 3:40 AM, Artur Pietrek <pietreka at gmail.com> wrote: > > Hi all > > Ups, I'm really sorry for that previous message, I've sent it by mistake. > > > > So let me write it once more. > > > > I've

> Message: 3 > Date: Sun, 3 Jul 2016 17:49:50 -0700 > From: Michael Lewis via llvm-dev <llvm-dev at lists.llvm.org> > To: Hayden Livingston <halivingston at gmail.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] Status of stack walking in LLVM on Win64? > Message-ID: > <CAEm7p3svyOi6JU6r_RCCtRfGhTgTHeRw-SR0iD+9Edv2pi71Dw at

Hi llvm-dev, >> The CopyFromReg->CopyToReg->CopyFromReg sequence doesn’t have the chains set correctly: the second CopyFromReg’s input chain isn’t connected to the CopyToReg’s output chain. (This appears to be the same problem in both graphs.) The DAG mentioned was generated by the SelectionDAGBuilder and as much as possible, we only modify the files within our target so I tried

 > These is metadata for epilogues (UWOP_EPILOG) but it is only available on Windows 8.1 and newer. I'm aware of this. I believe it is so sampling profilers can walk the kernel stack including through paged code -- i.e. the epilogue data is not paged, while the related epilogue code might be. Do you see it used, i.e. in usermode?  (where the pdata/xdata/code are all equally paged). It