Displaying 20 results from an estimated 23 matches for "getcommonsubclass".
2019 Aug 27
2
TargetRegisterInfo::getCommonSubClass bug, perhaps.
...Selection correct : i32 = ADDrr i32, i32
*** MachineFunction at end of ISel ***
# Machine code for function _Z11scalar_loopPsS_ss: IsSSA, TracksLiveness
...
%31:sfgpr32 = ADDrr killed %32:sgpr32, %27:sgpr32
...
Here should not select f32 sfgpr32 register, debugger point to
TargetRegisterInfo:: getCommonSubClass(const TargetRegisterClass *A,
const TargetRegisterClass *B,
const MVT::SimpleValueType SVT =
MVT::SimpleValueType::Any)
This function has been called 10+ in LLVM, only one place give
specific SVT parameter. Most of those places are hard to...
2017 May 05
2
problem with non-allocatable register classes
...(for example, GPRs plus PC and SP). So I defined them as non-allocatable, and defined separate classes for use in the allocator.
The problem is that tablegen does all kinds of clever analysis of the register classes, determining subsets and supersets and such, which are used to answer methods like getCommonSubClass(). In some cases it synthesizes new classes, which may or may not be allocatable depending on how the non-allocatable classes get mixed in. If a function like getCommonSubClass() returns a non-allocatable class, bad things happen (e.g. assertion failures from setRegClass()).
It seems to me that fu...
2011 Jun 21
2
[LLVMdev] Register class proliferation
...asses? Is it still a valid reason?
>>
>
> As I recall, it's a performance issue, as some of the algorithms involved were non-linear and expensive. I think you've refactored most of that away by now, though.
I can't think of any super-linear algorithms remaining except for getCommonSubClass() which could easily be fixed. I've never seen it show up on a Shark trace, though.
If we give each register class a bit vector of sub-classes, the currently linear isSubClass() / isSuperClass() would become constant time, and getCommonSubClass() could be made linear with CountTrailingZeros(A...
2011 Jun 22
0
[LLVMdev] Register class proliferation
...alid reason?
>>>
>>
>> As I recall, it's a performance issue, as some of the algorithms involved were non-linear and expensive. I think you've refactored most of that away by now, though.
>
> I can't think of any super-linear algorithms remaining except for getCommonSubClass() which could easily be fixed. I've never seen it show up on a Shark trace, though.
>
> If we give each register class a bit vector of sub-classes, the currently linear isSubClass() / isSuperClass() would become constant time, and getCommonSubClass() could be made linear with CountTraili...
2011 Jun 21
0
[LLVMdev] Register class proliferation
On Jun 21, 2011, at 8:51 AM, Jakob Stoklund Olesen wrote:
> In the past, I've seen some pushback on the list against adding more register classes. You can see it in the code as well, TargetLowering::getRegClassForInlineAsmConstraint() returns a vector of registers instead of a real register class.
>
> What is the reason we don't like adding register classes? Is it still a valid
2011 Jun 21
2
[LLVMdev] Register class proliferation
In the past, I've seen some pushback on the list against adding more register classes. You can see it in the code as well, TargetLowering::getRegClassForInlineAsmConstraint() returns a vector of registers instead of a real register class.
What is the reason we don't like adding register classes? Is it still a valid reason?
The new register allocators, fast and greedy, don't care at
2015 Oct 05
2
handling "overlapping" register classes
I'm working on generating code for a machine that has a register set kind
of like the 68000.
For those who don't recall, the 68K has 8 Data registers that can be used
for ordinary integer
instructions like add, subtract, multiply, shift, etc., and 8 Address
registers that can be use for
integer addition and a few other things, especially base registers for
addressing modes.
The Data
2015 Aug 25
2
[LLVMdev] TableGen Register Class not matching for MI in 3.6
...pNum < II->getNumOperands())
> DstRC = TRI->getAllocatableClass(TII->getRegClass(*II,IIOpNum,TRI,*MF));
> if (DstRC && !MRI->constrainRegClass(VReg, DstRC, MinRCSize)) {
> unsigned NewVReg = MRI->createVirtualRegister(DstRC);
> if (TRI->getCommonSubClass(DstRC,
> TRI->getRegClass(II->OpInfo[IIOpNum].RegClass))
What I was saying was this II->OpInfo[IIOpNum].RegClass looks to return DstRC at first glance.
What you want is TRI->getRegClass(VReg).
BTW, now with the full snippet, I see your mistake. You are passing a RegClass...
2015 Aug 25
2
[LLVMdev] TableGen Register Class not matching for MI in 3.6
...erands())
>> DstRC =
>> TRI->getAllocatableClass(TII->getRegClass(*II,IIOpNum,TRI,*MF));
>> if (DstRC && !MRI->constrainRegClass(VReg, DstRC, MinRCSize)) {
>> unsigned NewVReg = MRI->createVirtualRegister(DstRC);
>> if (TRI->getCommonSubClass(DstRC,
>> TRI->getRegClass(II->OpInfo[IIOpNum].RegClass))
>>
>>
>> What I was saying was this II->OpInfo[IIOpNum].RegClass looks to return
>> DstRC at first glance.
>> What you want is TRI->getRegClass(VReg).
>>
>> BTW, now with...
2015 Aug 25
4
[LLVMdev] TableGen Register Class not matching for MI in 3.6
...;getNumOperands())
>> DstRC = TRI->getAllocatableClass(TII->getRegClass(*II,IIOpNum,TRI,*MF));
>> if (DstRC && !MRI->constrainRegClass(VReg, DstRC, MinRCSize)) {
>> unsigned NewVReg = MRI->createVirtualRegister(DstRC);
>> if (TRI->getCommonSubClass(DstRC,
>> TRI->getRegClass(II->OpInfo[IIOpNum].RegClass))
>
> What I was saying was this II->OpInfo[IIOpNum].RegClass looks to return DstRC at first glance.
> What you want is TRI->getRegClass(VReg).
>
> BTW, now with the full snippet, I see your mistake...
2015 Aug 25
2
[LLVMdev] TableGen Register Class not matching for MI in 3.6
...ts && TLI->isTypeLegal(Node->getSimpleValueType(i))) {
const TargetRegisterClass *VTRC =
TLI->getRegClassFor(Node->getSimpleValueType(i));
errs()<<"CVR VTRC: "<<VTRC->getID()<<"\n";
if (RC)
VTRC = TRI->getCommonSubClass(RC, VTRC);
if (VTRC)
RC = VTRC;
}
VTRC = GPRRegs. Then RC=VTRC makes RC = GPRRegs.
the TLI info is from addRegisterClass(...) I'm assuming, which is defined
as GPRRegs in XXXISelLowering.cpp.
It seems this is where it gets constrained even more. Honestly, I really
don't...
2015 Aug 25
2
[LLVMdev] TableGen Register Class not matching for MI in 3.6
...ypeLegal(Node->getSimpleValueType(i))) {
> const TargetRegisterClass *VTRC =
> TLI->getRegClassFor(Node->getSimpleValueType(i));
> errs()<<"CVR VTRC: "<<VTRC->getID()<<"\n";
> if (RC)
> VTRC = TRI->getCommonSubClass(RC, VTRC);
> if (VTRC)
> RC = VTRC;
> }
>
> VTRC = GPRRegs. Then RC=VTRC makes RC = GPRRegs.
> the TLI info is from addRegisterClass(...) I'm assuming, which is defined
> as GPRRegs in XXXISelLowering.cpp.
>
> It seems this is where it gets constrain...
2015 Aug 25
2
[LLVMdev] TableGen Register Class not matching for MI in 3.6
...tSimpleValueType(i))) {
>> const TargetRegisterClass *VTRC =
>> TLI->getRegClassFor(Node->getSimpleValueType(i));
>> errs()<<"CVR VTRC: "<<VTRC->getID()<<"\n";
>> if (RC)
>> VTRC = TRI->getCommonSubClass(RC, VTRC);
>> if (VTRC)
>> RC = VTRC;
>> }
>>
>> VTRC = GPRRegs. Then RC=VTRC makes RC = GPRRegs.
>> the TLI info is from addRegisterClass(...) I'm assuming, which is defined
>> as GPRRegs in XXXISelLowering.cpp.
>>
>> It s...
2015 Aug 24
2
[LLVMdev] TableGen Register Class not matching for MI in 3.6
> On Aug 24, 2015, at 1:30 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:
>
> I'm trying to do something like this:
>
> // Dst = NewVReg's reg class
> // *II = MCInstrDesc
> // IIOpNum = II Operand Num
>
> if (TRI->getCommonSubClass(DstRC, TRI->getRegClass(II->OpInfo[IIOpNum].RegClass)) == DstRC)
> MRI->setRegClass(VReg, DstRC);
> else
> BuildMI(... TargetOpcode::COPY...)
>
> The condition is trying to reset the reg class if the DstRC reg class is valid for the operand num of the machine inst...
2015 Aug 25
2
[LLVMdev] TableGen Register Class not matching for MI in 3.6
...I->getRegClass(*II,IIOpNum,TRI,*MF));
>>>>>>>> if (DstRC && !MRI->constrainRegClass(VReg, DstRC, MinRCSize)) {
>>>>>>>> unsigned NewVReg = MRI->createVirtualRegister(DstRC);
>>>>>>>> if (TRI->getCommonSubClass(DstRC,
>>>>>>>> TRI->getRegClass(II->OpInfo[IIOpNum].RegClass))
>>>>>>>>
>>>>>>>>
>>>>>>>> What I was saying was this II->OpInfo[IIOpNum].RegClass looks to
>>>>>>>...
2015 Aug 25
2
[LLVMdev] TableGen Register Class not matching for MI in 3.6
...ableClass(TII->getRegClass(*II,IIOpNum,TRI,*MF));
>>>>>>> if (DstRC && !MRI->constrainRegClass(VReg, DstRC, MinRCSize)) {
>>>>>>> unsigned NewVReg = MRI->createVirtualRegister(DstRC);
>>>>>>> if (TRI->getCommonSubClass(DstRC,
>>>>>>> TRI->getRegClass(II->OpInfo[IIOpNum].RegClass))
>>>>>>>
>>>>>>>
>>>>>>> What I was saying was this II->OpInfo[IIOpNum].RegClass looks to
>>>>>>> return DstRC at...
2012 Jul 26
0
[LLVMdev] X86 sub_ss and sub_sd sub-register indexes
Jakob Stoklund Olesen <jolesen at apple.com> writes:
> These sub-registers are special, they are only mentioned here:
>
> let CompositeIndices = [(sub_ss), (sub_sd)] in {
> def XMM0: Register<"xmm0">, DwarfRegNum<[17, 21, 21]>;
> def XMM1: Register<"xmm1">, DwarfRegNum<[18, 22, 22]>;
> ...
I'm confused. Below you
2017 Jul 28
3
Purpose of various register classes in X86 target
Hello Matthias,
On 28 July 2017 at 04:13, Matthias Braun <mbraun at apple.com> wrote:
> It's not that hard in principle:
> - A register class is a set of registers.
> - Virtual Registers have a register class assigned.
> - If you have register constraints (like x86 8bit operations only work on
> al,ah,etc.) then you have to create a new register class to express that.
2012 Jul 26
2
[LLVMdev] X86 sub_ss and sub_sd sub-register indexes
All,
I've been trying to simplify the way LLVM models sub-register relationships a bit, and the X86 sub_ss and sub_sd sub-register indices are getting in the way. I want to get rid of them.
These sub-registers are special, they are only mentioned here:
let CompositeIndices = [(sub_ss), (sub_sd)] in {
def XMM0: Register<"xmm0">, DwarfRegNum<[17, 21, 21]>;
def
2012 Jul 26
2
[LLVMdev] X86 sub_ss and sub_sd sub-register indexes
...sters are spilled with 128-bit stores.
When the register coalescer removes a copy between VR128 and FR64 registers, it chooses the larger spill size for the result. This is the same for sub-register copies and full register copies.
The important point here is that VR128 is a sub-class of FR64, so getCommonSubClass(VR128, FR64) -> VR128. This is the Liskov substitution principle for register classes.
/jakob