similar to: Register spilling in caller saved backend

I have an issue that I've been wrestling with for quite some time and I'm hoping that someone with a deeper understanding of the register allocator can help me with. Namely, I am trying to teach RA to split a live range rather than allocating a CSR. I've attempted a very large number of tweaks to the costs (both existing and experimental ones that I've added). However, despite all

Hi I'm working on the XCore target and am having difficulty building libgcc. Background: If I use a libgcc built by llvm3.0-gcc with my current clang-llvm3.3 compiler, exceptions 'seem' to work. Trying to rebuild libgcc however breaks exception handling - they aren't caught! I thus assumed I needed to focus on the unwind code and particularly functions that call

When compiling C code below for AArach64, I saw that shrink-wrapping didn't happen due to the very early uses of CSRs in the entry block. So CSR spills/reloads are executed even when the early exit block is taken. int getI(int i); int foo(int *P, int i) { if (i>0) return P[i]; i = getI(i); return P[i]; } It's not that hard to find such cases where

Hi Graham, Thanks for sharing this. Are you planning on enabling the pass only on PGO? Even in non-PGO, I noticed some performance gains when we are aggressive in partially inlining the early return part, especially when the callee spill CSRs in the entry block. At a high level, I have two questions: 1. What is the main obstacle that prevent the pass from being enabled by default? 2.

On 2017-10-27 19:50, Hal Finkel wrote: > On 10/27/2017 03:32 PM, Jun Lim via llvm-dev wrote: > >> When compiling C code below for AArach64, I saw that shrink-wrapping >> didn't happen due to the very early uses of CSRs in the entry block. >> So CSR spills/reloads are executed even when the early exit block is >> taken. >> >> int getI(int i); >>

On 2017-11-14 17:22, Quentin Colombet wrote: > Hi, > > I think it is kind of artificial to tie the CSRCost with the presence > of calls. > I think I’ve already mentioned it in one of the review, but I > believe it would be better to differentiate when we want to use a CSR > to avoid spilling or to avoid splitting. CSR instead of spilling is > good, CSR instead of

On 2017-11-10 07:47, Nemanja Ivanovic wrote: > One thing I thought about doing a while back and never really wrote a > POC for is the following: > - Make FirstCSRCost a property of the MachineBasicBlock (or create a > map of MBB* -> FirstCSRCost) > > - Implement a pre-RA pass that will populate the map as follows: > > - Identify all blocks with calls > > -

On 2017-11-17 13:10, Quentin Colombet wrote: >> On Nov 16, 2017, at 2:31 PM, junbuml at codeaurora.org wrote: >> On 2017-11-14 17:22, Quentin Colombet wrote: >> >>> Hi, >>> I think it is kind of artificial to tie the CSRCost with the >>> presence >>> of calls. >>> I think I’ve already mentioned it in one of the review, but I

On 2017-10-30 21:20, Hal Finkel wrote: > On 10/30/2017 12:20 PM, junbuml at codeaurora.org wrote: >> On 2017-10-27 19:50, Hal Finkel wrote: >>> On 10/27/2017 03:32 PM, Jun Lim via llvm-dev wrote: >>> >>>> When compiling C code below for AArach64, I saw that shrink-wrapping >>>> didn't happen due to the very early uses of CSRs in the entry

Hi all, We would like to contribute a new backend for the Lanai processor (derived from the processor described in [1]). Lanai is a simple in-order 32-bit processor with: * 32 32-bit registers, including: * 2 registers with fixed values; * 4 used for program state tracking (PC, SP, FP, RCA); * 2 reserved for explicit usage by user (R10 and R11), used in threading library; * Up

The ISA & encoding is documented in the comments and diagrams of lib/Target/Lanai/LanaiInstrFormats.td. If that makes sense I'll add a link to this tablegen in docs/CompilerWriterInfo.rst. Thanks, Jacques On Tue, Feb 9, 2016 at 2:12 PM, Sean Silva <chisophugis at gmail.com> wrote: > Do you have a psABI document? Or an ISA reference? Or an encoding > reference? > > I

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,

Do you MC support? Cheers, Rafael On Feb 9, 2016 1:12 PM, "Jacques Pienaar via llvm-dev" < llvm-dev at lists.llvm.org> wrote: > > > On Tue, Feb 9, 2016 at 10:05 AM, Chandler Carruth <chandlerc at google.com> > wrote: > >> On Tue, Feb 9, 2016 at 9:58 AM Hal Finkel via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>>

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

Hi, I noticed some performance gains in some spec benchmarks without significant code size bloat when aggressively performing partial inlining, especially when the original callee spill CSRs in the entry block. I guess the partial inlining is not enabled mainly due to the code size. Is there any other issue which prevent the pass from being enabled? Do we have any plan or any on-going works

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

On Tue, Feb 9, 2016 at 9:58 AM Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > ----- Original Message ----- > > From: "Jacques Pienaar via llvm-dev" <llvm-dev at lists.llvm.org> > > To: llvm-dev at lists.llvm.org > > Sent: Tuesday, February 9, 2016 11:40:21 AM > > Subject: [llvm-dev] [RFC] Lanai backend > > > Hi all, >

That breaks the whole IR idea of using alloca to allocate/denote space for local variables, and then optimize those into SSA values when optimization proves that is OK. Also, for a lot of things, that attribute is simply impossible to implement. Any value that is live across a call needs to be spilled to memory. You cannot put an unspillable value in a callee preserved register, because you

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

Hi all, I've been trying to figure out if there is a feasible way to prevent values from ever spilling from registers to the stack. I've looked for code or documentation on how to do this but haven't found anything, apologies if this has already been done. Recent security research has shown that protection schemes such as CFI (that might otherwise be secure) are undermined by