Displaying 20 results from an estimated 24 matches for "gprregs".
2015 Aug 25
2
[LLVMdev] TableGen Register Class not matching for MI in 3.6
BB#0: derived from LLVM BB %entry
%vreg0<def> = MOV16Copy_IMM_REG <ga:@a+1>[TF=1]; GPRRegs:%vreg0
%vreg1<def> = COPY %vreg0; PTRRegs:%vreg1 GPRRegs:%vreg0
Send_iii %NULLR0, %vreg1<kill>, 1, 1, 1, 1, 0; PTRRegs:%vreg1
RetRA
This is what I get. This is what I'd like to get:
BB#0: derived from LLVM BB %entry
%vreg0<def> = MOV16Copy_IMM_REG <ga:@a+1>[TF=...
2015 Aug 25
2
[LLVMdev] TableGen Register Class not matching for MI in 3.6
...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 understand this part at all, why even have t...
2015 Aug 25
2
[LLVMdev] TableGen Register Class not matching for MI in 3.6
...st 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 understand this part at all, why even have this type checking? If we...
2015 Aug 25
2
[LLVMdev] TableGen Register Class not matching for MI in 3.6
...ue, Aug 25, 2015 at 1:02 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:
>
>> Quentin,
>>
>> 1. I'll take a look, it's also picking the reg class by the
>> SimpleValueType and then getting the common subclass. Choosing to constrain
>> the reg class to GPRRegs instead of GPRBaseRegs seems like it could lead to
>> unintended spilling? If GPRBaseRegs was used then you could have the base
>> reg class to choose from instead of spilling.
>>
>
> Before spilling we try splitting, which relax the constraint on the
> registers.
> E....
2015 Aug 25
2
[LLVMdev] TableGen Register Class not matching for MI in 3.6
...6, immSExt16x>;
On Tue, Aug 25, 2015 at 1:02 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:
> Quentin,
>
> 1. I'll take a look, it's also picking the reg class by the
> SimpleValueType and then getting the common subclass. Choosing to constrain
> the reg class to GPRRegs instead of GPRBaseRegs seems like it could lead to
> unintended spilling? If GPRBaseRegs was used then you could have the base
> reg class to choose from instead of spilling.
> 2. Ok, yes, that makes sense.
> 3. I'll send a second email.
>
> Thanks.
>
> On Tue, Aug 2...
2015 Jul 31
4
[LLVMdev] TableGen Register Class not matching for MI in 3.6
...ter, which is what
> we want
> >
> > In 3.6, we now get this:
> >
> > mov @a, %r0 // r0 = gpr
> > mov %r0, %b1 // b1 = base reg
> >
> > The register class looks like this:
> >
> > def ARegs : RegisterClass<"us", [i16], i16, (add GPRRegs, IndexRegs,
> BaseRegs)>;
> >
> > I have absolutely no idea why this is not matching any longer?
> >
> > The fix here is to define an MI with explicit single register class (ie
> it only allows PTRRegs as the destination).
> >
> > This must be an issue w...
2015 Aug 19
2
[LLVMdev] TableGen Register Class not matching for MI in 3.6
...class assignment is based on
uses and is instead inserting an extra COPY for this. Is this accurate? If
so, why?
In this above example, I'm getting an extra "mov %r0, $b1" (this is an
MI::COPY) even though "mov @a, %b1" (this is an MI::MOV) is entirely
acceptable since both GPRRegs and BaseRegs are in the reg class list..
If the heuristic is simply picking the first available reg class or the reg
class with the most available, for example, instead of picking the reg
class based on uses, I will have to change this heuristic to reduce code
bloat, or we'll have to add backe...
2015 Aug 19
3
[LLVMdev] TableGen Register Class not matching for MI in 3.6
Yes, you're probably right about the ID. The odd part is that I have other
simpler instructions that use the same type of superset and it always, so
far, matches correctly (it doesn't just pick GPRRegs all the time).
Like I said, we can just 'fill in the gaps' with new MIs but that sure
seems like a brush off solution. The td files would be so much cleaner if
you could have a superset reg class that actually matched the correct reg
usage (which it sort of does in AddRegisterOperand when...
2012 Jul 25
2
[LLVMdev] Question about an unusual jump instruction
...instruction (called DECJNZ) that decrements a register and, if the
decremented value is not zero, jumps (with a relative jump) to a given offset.
I've described in tablegen this instruction as follow:
def DECJNZ : Instruction {
let Namespace = "MyTarget";
let OutOperandList = (outs GprRegs:$R0);
let InOperandList = (ins GprRegs: $R1, imm16:$dest);
let AsmString = "DECJNZ $R0, $dest";
let isBranch = 1;
let isTerminator = 1;
let Constraints = "$R1 = $R0";
let Defs = [SR];
}
I would like to create an optimization pass to make countable loops faster by
using this in...
2015 Aug 19
2
[LLVMdev] TableGen Register Class not matching for MI in 3.6
...ctly the same but still
> you are seeing a different result of instruction selection.
>
>
> In this above example, I'm getting an extra "mov %r0, $b1" (this is an
> MI::COPY) even though "mov @a, %b1" (this is an MI::MOV) is entirely
> acceptable since both GPRRegs and BaseRegs are in the reg class list..
>
> If the heuristic is simply picking the first available reg class or the
> reg class with the most available, for example, instead of picking the reg
> class based on uses, I will have to change this heuristic to reduce code
> bloat, or we&...
2015 Aug 25
4
[LLVMdev] TableGen Register Class not matching for MI in 3.6
...Taylor <ryta1203 at gmail.com <mailto:ryta1203 at gmail.com>> wrote:
>>>> Yes, you're probably right about the ID. The odd part is that I have other simpler instructions that use the same type of superset and it always, so far, matches correctly (it doesn't just pick GPRRegs all the time).
>>>>
>>>> Like I said, we can just 'fill in the gaps' with new MIs but that sure seems like a brush off solution. The td files would be so much cleaner if you could have a superset reg class that actually matched the correct reg usage (which it sort o...
2015 Aug 24
2
[LLVMdev] TableGen Register Class not matching for MI in 3.6
...04 PM, Ryan Taylor <ryta1203 at gmail.com <mailto:ryta1203 at gmail.com>> wrote:
> Yes, you're probably right about the ID. The odd part is that I have other simpler instructions that use the same type of superset and it always, so far, matches correctly (it doesn't just pick GPRRegs all the time).
>
> Like I said, we can just 'fill in the gaps' with new MIs but that sure seems like a brush off solution. The td files would be so much cleaner if you could have a superset reg class that actually matched the correct reg usage (which it sort of does in AddRegisterOpe...
2012 Jul 25
0
[LLVMdev] Question about an unusual jump instruction
...decrements a register and, if the
> decremented value is not zero, jumps (with a relative jump) to a given offset.
>
> I've described in tablegen this instruction as follow:
>
> def DECJNZ : Instruction {
> let Namespace = "MyTarget";
> let OutOperandList = (outs GprRegs:$R0);
> let InOperandList = (ins GprRegs: $R1, imm16:$dest);
> let AsmString = "DECJNZ $R0, $dest";
> let isBranch = 1;
> let isTerminator = 1;
> let Constraints = "$R1 = $R0";
> let Defs = [SR];
> }
>
> I would like to create an optimization pass to m...
2017 Feb 15
5
Unsigned int displaying as negative
Where does the unsignedSub come from?
On 2017-02-15 20:38, Ryan Taylor wrote:
> Sorry, it should be:
>
> defm SUB16u_ : ABD_NonCommutative<"sub16u", unsignedSub, LOADRegs,
> GPRRegs, DSTRegs, i16, i16, i16, uimm16, immZExt16x>;
>
> On Wed, Feb 15, 2017 at 2:37 PM, Ryan Taylor <ryta1203 at gmail.com>
> wrote:
>
>> I see. If I put simm16 and immSExt16x in place of uimm16 and
>> immZExt16x
>> respectively, the imm matches but it prints o...
2008 Jan 17
2
[LLVMdev] specifying accumulator based load/stores
...t;st" above)
The problem with the generated code is incorrectly assuming that value in
"acc" is still live.
for example, for code like below
a = 3;
b = 4;
c = 3;
it generates:
mov 3, acc
st acc, @a
mov 4, acc
st acc, @b
st acc, @c (Wrong)
When I use the GPRRegs, which has more regs, the code is ok.
is it because I still haven't implemented the stack/frame related routines
and the value in acc is getting spilled to stack and reloaded?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llv...
2015 Aug 24
2
[LLVMdev] TableGen Register Class not matching for MI in 3.6
...M, Ryan Taylor <ryta1203 at gmail.com <mailto:ryta1203 at gmail.com>> wrote:
>> Yes, you're probably right about the ID. The odd part is that I have other simpler instructions that use the same type of superset and it always, so far, matches correctly (it doesn't just pick GPRRegs all the time).
>>
>> Like I said, we can just 'fill in the gaps' with new MIs but that sure seems like a brush off solution. The td files would be so much cleaner if you could have a superset reg class that actually matched the correct reg usage (which it sort of does in AddReg...
2015 Jul 30
2
[LLVMdev] TableGen Register Class not matching for MI in 3.6
....4, we would get something like this:
mov @a, %b1 // moving this immediate to a base register, which is what we
want
In 3.6, we now get this:
mov @a, %r0 // r0 = gpr
mov %r0, %b1 // b1 = base reg
The register class looks like this:
def ARegs : RegisterClass<"us", [i16], i16, (add GPRRegs, IndexRegs,
BaseRegs)>;
I have absolutely no idea why this is not matching any longer?
The fix here is to define an MI with explicit single register class (ie it
only allows PTRRegs as the destination).
This must be an issue with something else and not the tablegen but if that
was the case I&...
2015 Aug 25
2
[LLVMdev] TableGen Register Class not matching for MI in 3.6
...yan Taylor <ryta1203 at gmail.com <mailto:ryta1203 at gmail.com>> wrote:
>>> Yes, you're probably right about the ID. The odd part is that I have other simpler instructions that use the same type of superset and it always, so far, matches correctly (it doesn't just pick GPRRegs all the time).
>>>
>>> Like I said, we can just 'fill in the gaps' with new MIs but that sure seems like a brush off solution. The td files would be so much cleaner if you could have a superset reg class that actually matched the correct reg usage (which it sort of does i...
2015 Aug 25
2
[LLVMdev] TableGen Register Class not matching for MI in 3.6
...t;>> wrote:
>>>>
>>>>> Yes, you're probably right about the ID. The odd part is that I have
>>>>> other simpler instructions that use the same type of superset and it
>>>>> always, so far, matches correctly (it doesn't just pick GPRRegs all the
>>>>> time).
>>>>>
>>>>> Like I said, we can just 'fill in the gaps' with new MIs but that sure
>>>>> seems like a brush off solution. The td files would be so much cleaner if
>>>>> you could have a superset...
2008 Jan 17
0
[LLVMdev] specifying accumulator based load/stores
...> value in "acc" is still live.
> for example, for code like below
>
> a = 3;
> b = 4;
> c = 3;
>
>
> it generates:
>
> mov 3, acc
> st acc, @a
> mov 4, acc
> st acc, @b
> st acc, @c (Wrong)
>
>
> When I use the GPRRegs, which has more regs, the code is ok.
> is it because I still haven't implemented the stack/frame related
> routines and the value in acc is getting spilled to stack and
> reloaded?
It's very hard to tell what's going on without having access to your
backend. If you dump...