similar to: How to prevent registers from spilling?

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

Hi, I'm trying to implement my ideas about better garbage collection support [1]. The hardest problem seems to be to find all registers that are live at safe points (for example, during a call) and spilling them. Since nobody responded on the original thread, I decided to start a new thread specifically for this question. The problem is to safe registers that contain gc pointers to the stack

On Sep 3, 2013, at 17:21 , Manuel Jacob <me at manueljacob.de> wrote: > The problem is to safe registers that contain gc pointers to the stack > before a call and reload them after the call. Is there an Analysis Pass > that computes information about which registers are live during a > specific instruction? I looked at LiveIntervals and LiveVariables, but > they seem to be for

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

> On Nov 19, 2015, at 9:50 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > > On 19 Nov 2015, at 17:49, Quentin Colombet <qcolombet at apple.com> wrote: >> >> I must miss something, but I don’t get what is the problem of lower the pointer to actual integer. > > Pointers, in our architecture, are not integers. Thanks for the clarifications. So

I'm working on an out-of-tree target and am having some problems with rematerialization and spilling. The target's load and store instructions affect the condition code register (CCR). Describing this in the InstrInfo.td file using Defs = [CCR] certainly prevents spills and fills from being inserted where they might clobber CCR but it also prevents the load instruction from being

s/llvm-commits/llvmdev/ On Dec 9, 2011, at 12:58 PM, Arnold Schwaighofer wrote: > >> As Jakob pointed out to me, the core problem is that the current >> register scavenger implementation will only give you one register; for >> the PowerPC case, and it looks like for your case as well, we might >> really need two registers. In the short term, a reasonable solution

Greetings LLVM Devs! I am a PhD student in the Secure Systems and Software Lab at UC Irvine. We have been working on adding randomness into code generation to create a diverse population of binaries. This diversity prevents code-reuse attacks such as return-oriented-programming (ROP) by denying the attacker information about the exact code layout. ROP has been used is several high-profile recent

Given an architecture with two classes of registers: A is general purpose and has an "adequate" number of registers, and C which is special purpose and has very few (e.g. one) register. There are cheap instructions that directly copy from C to A and vice versa. If we need another C register and they are all live, we need to spill one. Currently as far as I can tell, the only way to

> I am not sure extending the scavenger is the right way to go about this. > > There are two different situations where we might need extra registers to > spill something: > > 1. When spilling a weird register class like predicate registers, we > already known during register allocation that we will need a scratch GPR > to assist with the spill. > > 2. When spilling

Hi Brian, +1 on what Nemanja said: specifying large register classes is the key. More details here: http://lists.llvm.org/pipermail/llvm-dev/2019-December/137700.html <http://lists.llvm.org/pipermail/llvm-dev/2019-December/137700.html> Cheers, -Quentin > On Sep 9, 2020, at 11:13 AM, Nemanja Ivanovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On PowerPC, we

Hi Quentin, Let me clarify if I understood this correctly. If the accesses (writes and reads) to sub-registers are expressed always as sub-registers of the super-register register class (e.g., SuperReg.sub1;), then the spilling decision is for the super register. But, if the accesses are in terms of the register class of the sub-registers directly (SubReg;), then the spilling decision will

I still think my answer applies that you have to modify storeRegToStackSlot()/loadRegFromStackSlot(). They decide how registers are spilled and reloaded. Nobody is stopping you from using super registers spills/reloads to implement spilling/reloading smaller registers there. - Matthias > On Jan 30, 2018, at 10:21 AM, ahmede <ahmede at ece.ubc.ca> wrote: > > Hi Quentin, > >

Hi Matthias, No. I want the register allocator to spill the super-register (the large one e.g., 64-bit) and not just the sub-register (e.g., the 32-bit that is a piece of of the 64-bit register) because the stack loads/store width is 64-bit in this example. RegClass1 (sub-registers): sub_registers (32-bit) --> can be natively used in arithmetic operations but no stack

On Jun 3, 2013, at 6:05 AM, Steve Montgomery <stephen.montgomery3 at btinternet.com> wrote: > I'm working on an out-of-tree target and am having some problems with rematerialization and spilling. > > The target's load and store instructions affect the condition code register (CCR). Describing this in the InstrInfo.td file using Defs = [CCR] certainly prevents spills and

To make my point clear, I believe an implementation of storeRegToStackSlot()/loadRegFromStackSlot() is not sufficient (as it received the physical register already). Does this make sense? On 2018-01-30 13:33, ahmede wrote: > Right Matthias, I am aware that an implementation for > storeRegToStackSlot()/loadRegFromStackSlot() is necessary. But these > functions receive the physical

Right Matthias, I am aware that an implementation for storeRegToStackSlot()/loadRegFromStackSlot() is necessary. But these functions receive the physical register that need to be spilled, they might receive the sub-register. In this case, using the super-register naively is unsafe (e.g., one might overwrite parts of it). Thus, I think the register allocator/spillar need to be aware of the

Hi Ahmed, If you access your values with sub-registers indices, IIRC the inline spiller will spill the super register. If you access your values directly (via sub-regclass), then the spiller uses this class. Basically what I am saying is the spiller spills the value that contains the accesses. E.g., = v; will spill v = v.sub1; will spill v too, but v is a super register in that case. Cheers,

Hi, I wonder if there is a way in LLVM to disable spilling a register-class while still enabling the super-registers of this register-class to be spilled. If not, how can we implement spilling for sub-registers when stack load/stores can only operate on the super registers? Is there a way even if it is suboptimal? Thanks, Ahmed

On 8/28/13 4:37 PM, Nick Lewycky wrote: > On 26 August 2013 11:39, Stephen Crane <sjcrane at uci.edu > <mailto:sjcrane at uci.edu>> wrote: > > Greetings LLVM Devs! > > I am a PhD student in the Secure Systems and Software Lab at UC > Irvine. We have been working on adding randomness into code generation > to create a diverse population of