similar to: [LLVMdev] Trouble with virtual registers

I start my porting for picoblaze,the soft cpu for fpga ,which is designed by XILINX from MSP430 porting . After some day's work , somethinig looks good , for it can generate for some simple C program: eg : int f1(int a) { return a+1; } but it failed with this : char f() { char a; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++;

Our out-of-tree LLVM compiler is configured and built on Linux, but I cannot get it to run under the Windows 10 Linux Subsystem. When run in this context it reports a crash: warning: Error disabling address space randomisation: Success warning: linux_ptrace_test_ret_to_nx: PTRACE_KILL waitpid returned -1: Interrupted system call Program received signal SIGSEGV, Segmentation fault.

Hello, after some time I'm trying to build my code with the current CVS of LLVM, and have a problem. The mentioned file, around line 184, contains: if (FixedSlot == FixedSpillSlots+NumFixedSpillSlots) { // Nope, just spill it anywhere convenient. FrameIdx = FFI->CreateStackObject(RegInfo->getSpillSize(Reg)/8,

Hi Daniel, Thanks for replying; I was hoping to get in touch with you on this issue. I had a look at how SelectionIDAG does it when generating the matcher table, and it does consider the implicit defs as additional output. Here is the match table generated for the pattern: /* 0*/ OPC_CheckOpcode, TARGET_VAL(ISD::SIGN_EXTEND), /* 3*/ OPC_MoveChild0, /* 4*/ OPC_CheckOpcode,

On my (out-of-tree) target I have 16 128-bit registers. Unaligned load/store are illegal. (must 16-bytes aligned) 8 of those registers are defined as callee-saved and 8 caller-saved. The default stack size is 4 bytes. The target implements dynamic stack realign to make sure the stack will always be aligned correctly when necessary. Yet I am still getting unaligned load/store when running this

----- Original Message ----- > From: "Francois Pichet" <pichet2000 at gmail.com> > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, November 18, 2013 2:26:30 PM > Subject: [LLVMdev] Unaligned load/store for callee-saved 128-bit registers > > > > On my (out-of-tree) target I have 16 128-bit registers. >

----- Original Message ----- > From: "Hal Finkel" <hfinkel at anl.gov> > To: "Francois Pichet" <pichet2000 at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, November 18, 2013 2:45:53 PM > Subject: Re: [LLVMdev] Unaligned load/store for callee-saved 128-bit registers > > ----- Original

BTW I managed to get around this problem by flagging all the 128-bit registers as caller saved only. On my system, vector registers are more likely to be used on leaf functions anyway. On Thu, Nov 21, 2013 at 3:24 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Hal Finkel" <hfinkel at anl.gov> > > To: "Francois

----- Original Message ----- > From: "Francois Pichet" <pichet2000 at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chad Rosier" <mcrosier at codeaurora.org>, "Jakob Stoklund Olesen" <jolesen at apple.com>, "LLVM Developers Mailing > List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, November

Hi Lang. Thank you. I added pseudo-instructions for spill/reloads and expanded it in expandPostRAPseudo. Regards, Dmitriy. 04.03.2013 8:24, Lang Hames wrote: > Hi Dmitriy, > > As you've seen our current spill code assumes that spill/reloads are > single instructions. I think the best way to work around this is to > introduce load/store pseudo-instructions and expand these

Hi All. I'm writing storeRegToStackSlot and loadFromStackSlot function for my Target. This Target can store/load one byte (not all word) from FrameIndex. If I need to store 16 bit register I will must to split it to two instruction like this: BuildMI(MBB, MI, dl, get(Z80::LD8xmr)) .addFrameIndex(FrameIndex).addImm(0) .addReg(SrcReg, 0, Z80::subreg_lo); BuildMI(MBB, MI, dl,

Hi Dmitriy, As you've seen our current spill code assumes that spill/reloads are single instructions. I think the best way to work around this is to introduce load/store pseudo-instructions and expand these after register allocation. Cheers, Lang. On Sat, Feb 23, 2013 at 12:15 AM, Dmitriy Limonov <earl at excluzive.ws> wrote: > Hi All. > > I'm writing

Hi all, I am using the fast register allocator on a partially allocated machine function. I have noticed reserved registers (i.e. liveins) are marked as free after first use (in usePhysReg(..) method). This seems an error to me as a livein might be still used later in the basic block. As I understand this should check for isKill() before marking it as free, but I see it even *sets* the kill

Hi,   For a custom target, there is a pass to perform memory dependence analysis, where, i need to get memory pointer for "load instruction". I want to check the pointer alias behavior. I am getting this by considering the memoperands for the load instruction.   For "load instruction", Machine Instruction dumps as below:   vr12<def> = LD_Iri %vr2<kill>, 0;

Chris Lattner wrote: > On Sat, 13 May 2006, Vladimir Prus wrote: >> in LLVM CVS the afore-mentioned function has 'const TargetRegisterClass*' >> parameter, that is not documented. >> >> Can somebody explain what does it mean? > > Basically, it gives the target more information about the spill. In > particular, it specifies the register class to use

Hi llvmdev, I'm trying to figure how llvm remembers stack slots allotted to callee saved registers on x86. In particular, llvm pushes registers in decreasing order of FrameIdxs [1], so the offsets they get (as returned by MFI->getObjectOffset) don't directly correspond to their actual stack locations. In X86FrameLowering's emitCalleeSavedFrameMoves, when emitting DWARF

The patch is in http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080421/061548.html . Okay to commit :) On Thu, Apr 24, 2008 at 7:35 PM, Arnold Schwaighofer <arnold.schwaighofer at gmail.com> wrote: > Another round :) > > I'll post the patch to llvm-commits cause i guess people might get > annoyed by my series of patches :). > > On Tue, Apr 22, 2008 at

Hello everybody, hi Evan, this patch changes the lowering of arguments for tail call optimized calls. Before arguments that could be overwritten by each other were explicitly lowered to a stack slot, not giving the register allocator a chance to optimize. Now a sequence of copyto/copyfrom virtual registers ensures that arguments are loaded in (virtual) registers before they are lowered to the

On 31.5.2014 2:04, Pasi Parviainen wrote: > On 28.5.2014 2:57, Sanjoy Das wrote: >> Hi llvmdev, >> >> I'm trying to figure how llvm remembers stack slots allotted to callee >> saved registers on x86. In particular, llvm pushes registers in >> decreasing order of FrameIdxs [1], so the offsets they get (as >> returned by MFI->getObjectOffset) don't

Another round :) I'll post the patch to llvm-commits cause i guess people might get annoyed by my series of patches :). On Tue, Apr 22, 2008 at 10:34 PM, Evan Cheng <evan.cheng at apple.com> wrote: . >> +PPCTargetLowering::IsEligibleForTailCallOptimization(SDOperand Call, >> ... > That's fine. Please break it into two parts and move the target > independent part