similar to: [LLVMdev] Question about callee saved registers in x86

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

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

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

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 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: "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

----- 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. >

ola, ive been looking at adding support for an -msave-args option for use on x86_64. the short explanation of it is that it makes x86_64 function prologues store their register arguments on the stack. the purpose of this is to make the arguments trivially accessible for things like stack traces with arguments. as per https://blogs.oracle.com/sherrym/entry/obtaining_function_arguments_on_amd64,

----- 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

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

Dear list members, I need to translate 3 lines of matlab code to R (a loop, to be specific), and I don't know what would be the results in matlab or how to do it in R-- I don't realise if they are doing to the col, vector or what. if the results are a vector or a value or a matrix :-( Anyone with matlab, can run it and give me the result? Any ideias what am I doing wrong? The code is

Hi all, As part of my bachelor's thesis I'm trying to implement a new LLVM-based back end for the OCaml compiler. Currently I have a problem with LLVM's interface to the OCaml garbage collector. When I try to compile the attached program using llc I get the following stack dump: 0 llc 0x00000000016611de 1 llc 0x00000000016616aa 2 libpthread.so.0

## Problem description One of the responsibilities of a target's implementation of TargetFrameLowering::emitPrologue is to set the frame pointer (if needed). Typically, the frame pointer will be stored to the stack just like the other callee-saved registers, and emitPrologue must insert the instruction to change its value after it was stored to the stack. Mips does this by looking at the

Hello, While tuning the MIScheduler for my target, I discovered a code that unnecessarily restricts the scheduler. I think this is a bug, but I would appreciate a second opinion. In file ScheduleDAGInstrs.cpp, the function MIsNeedChainEdge determines whether two MachineInstrs are ordered by a memory dependence. It first runs through the standard criteria (Do both instructions access memory?

Team I have a Dell PowerEdge R720xd, with the Broadcom NetXtreme bcm5720. I found the following thread: http://forums.freebsd.org/showthread.php?t=31769 I find I am unable to use the NIC's (there are 4 on the server). When we put a cable into it we get a "watchdog timeout -- resetting" error, and the machine will pause for 5 or so seconds. IP may or may not come up randomly.

> On 28/10/2011 04:14, Jan Mikkelsen wrote: > >/ Hi, > />/ > />/ There is a patch linked to from this PR, which seems very similar: > />/ > />/ http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/140416 > />/ > />/ http://lists.freebsd.org/pipermail/freebsd-scsi/2011-March/004839.html > />/ > />/ The problem is also consistent with running

Hi, We bought a new Dell PowerEdge 2950III with Perc 6/i and have the disk geometry problem using 6.3 final or 7.0 RC1. Seems that we are not alone at least one guy has similar problem reported earlier: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2008-01/msg00506.html I was reading the mailing list and found that some of the people are happily using this hardware with the latest

Dear R-Helpers, I'm working with immunoassay data and 5PL logistic model. I wanted to experiment with different forms of weighting and parameter selection, which is not possible in instrument software, so I turned to R. I am using R 2.14.2 under Win7 64bit, and the 'nls' library to fit the model - I started with the same model and weighting type (1/y) as in the instrument to see

I'm writing a pass that looks at the operands of certain non-commutable instructions and swaps a couple of them if certain conditions exist (a register bank conflict in the instruction). If the conflict exists, I build a new instruction which has the 2nd and 3rd operands swapped (using BuildMI). Then I want to get rid of the original instruction. I had done some searching and found that

Thanks for the information. I still don't know how do I partition registers into different classes from the virtual registers? For instance, I have the function who which iterates over the instructions, but I don't know how to write the function which returns the different register class. void RAOptimal::Gather(MachineFunction &Fn) { // Gather just iterates over the blocks,