search for: regclass1

...the LinearScan register allocator tries to use same register for both live intervals, if the new interval is defined by a register copy whose destination reg is compatible with the source register. This is ok. However, this "check for compatibility" is wrongly done IMHO. Say I have regclass1 with reg A, and regclass2 with regs {A, B}, but regclass2 defines only "B" as allocatable by RA. A copy instruction: <regclass2 dst> = <regclass1 src> where src was allocated to register A will make dst be allocated also to A, even when it was defined as not allocatable i...

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 loads/stores for that width. RegClass2 (super-registers): [sub_register, subregister] (64-bit) --> can be natively used in arithmetic operations and can be used in lo...

...llocator tries to use same register for both > live intervals, if the new interval is defined by a register copy > whose destination reg is compatible with the source register. This is > ok. However, this "check for compatibility" is wrongly done IMHO. > > Say I have regclass1 with reg A, and regclass2 with regs {A, B}, but > regclass2 defines only "B" as allocatable by RA. The register allocator assumes in many places that a register is either allocatable or reserved independently of the register class. That is, if a register is allocatable in one regis...

...;> 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 >> loads/stores for that width. >> >> RegClass2 (super-registers): [sub_register, subregister] (64-bit) >> --> can be natively used in...

...; wrote: > > 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 loads/stores for that width. > > RegClass2 (super-registers): [sub_register, subregister] (64-bit) --> can be natively used in arithmetic operations and can be used...

...egister 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 >>>> loads/stores for that width. >>>> RegClass2 (super-registers): [sub_register, subregister] (64-bit) >>>> --> c...

Hi Jakob, >> Say I have regclass1 with reg A, and regclass2 with regs {A, B}, but >> regclass2 defines only "B" as allocatable by RA. > > The register allocator assumes in many places that a register is > either allocatable or reserved independently of the register class. Is there any reason for this? I...

...r 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 >>>>> loads/stores for that width. >>>>> RegClass2 (super-registers): [sub_register, subregister] (64-bit) >>>&...

...e: >>> 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 loads/stores for that width. >>> RegClass2 (super-registers): [sub_register, subregister] (64-bit) --> can be natively used in arithmetic operations and can be us...

> On Jan 29, 2018, at 1:20 PM, ahmede via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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. What would you have the register allocator do when it runs out of register and you have spilling disabled? Abort the

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