Displaying 20 results from an estimated 500 matches similar to: "[LLVMdev] Complex load patterns and token factors"
2012 Jun 23
0
[LLVMdev] Complex load patterns and token factors
On Sat, Jun 23, 2012 at 04:10:51PM -0500, Hal Finkel wrote:
> Working on a target I added this pattern:
>
> def : Pat<(v4i64 (load xoaddr:$src)),
> (QVFCTIDb (QVLFDXb xoaddr:$src))>;
>
> I'd like to fix this so that it works correctly: the TokenFactor
> inputs should be attached to all inner-most instructions. I'm guessing
> this is somewhere in
2012 Jun 24
2
[LLVMdev] Complex load patterns and token factors
On Sat, 23 Jun 2012 22:28:55 +0100
Tim Northover <t.p.northover at gmail.com> wrote:
> On Sat, Jun 23, 2012 at 04:10:51PM -0500, Hal Finkel wrote:
> > Working on a target I added this pattern:
> >
> > def : Pat<(v4i64 (load xoaddr:$src)),
> > (QVFCTIDb (QVLFDXb xoaddr:$src))>;
> >
> > I'd like to fix this so that it works
2012 Jun 24
0
[LLVMdev] Complex load patterns and token factors
On Sat, 23 Jun 2012 21:18:37 -0500
Hal Finkel <hfinkel at anl.gov> wrote:
> On Sat, 23 Jun 2012 22:28:55 +0100
> Tim Northover <t.p.northover at gmail.com> wrote:
>
> > On Sat, Jun 23, 2012 at 04:10:51PM -0500, Hal Finkel wrote:
> > > Working on a target I added this pattern:
> > >
> > > def : Pat<(v4i64 (load xoaddr:$src)),
> >
2012 Jun 24
2
[LLVMdev] Complex load patterns and token factors
On Sat, 23 Jun 2012 21:25:48 -0500
Hal Finkel <hfinkel at anl.gov> wrote:
> On Sat, 23 Jun 2012 21:18:37 -0500
> Hal Finkel <hfinkel at anl.gov> wrote:
>
> > On Sat, 23 Jun 2012 22:28:55 +0100
> > Tim Northover <t.p.northover at gmail.com> wrote:
> >
> > > On Sat, Jun 23, 2012 at 04:10:51PM -0500, Hal Finkel wrote:
> > > >
2009 Jan 15
2
[LLVMdev] Use two ComplexPatterns (possible bug of TableGen?)
On Wednesday 14 January 2009 18:59:03 Brandner Florian wrote:
> I have a patch against llvm 2.4 that fixes this issue, but did not have
> the time to post the patch here. I'll do so by tomorrow.
here is the patch, still against llvm 2.4. I had a short look on trunk, but it
seems that there are several conflicts. Maybe a tablgen expert should have a
look at this - I also do not know if
2009 Jan 16
1
[LLVMdev] Use two ComplexPatterns (possible bug of TableGen?)
Hi Dan,
thank you for applying the patch.
> However, I didn't apply this part:
>
> - if (InstPatNode && InstPatNode->getOperator()->getName() ==
> "set") {
> + if (InstPatNode && !InstPatNode->isLeaf() &&
> + InstPatNode->getOperator()->getName() == "set") {
>
> because I'm unsure what
2009 Jan 16
0
[LLVMdev] Use two ComplexPatterns (possible bug of TableGen?)
On Jan 15, 2009, at 12:50 AM, Brandner wrote:
> On Wednesday 14 January 2009 18:59:03 Brandner Florian wrote:
>> I have a patch against llvm 2.4 that fixes this issue, but did not
>> have
>> the time to post the patch here. I'll do so by tomorrow.
>
> here is the patch, still against llvm 2.4. I had a short look on
> trunk, but it
> seems that there are
2008 Jul 08
0
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
PPCTargetLowering::EmitInstrWithCustomInserter has a reference
to the current MachineFunction for other purposes. Can you use
MachineFunction::getRegInfo instead?
Dan
On Jul 8, 2008, at 1:56 PM, Gary Benson wrote:
> Would it be acceptable to change MachineInstr::getRegInfo from private
> to public so I can use it from
> PPCTargetLowering::EmitInstrWithCustomInserter?
>
>
2008 Jul 11
0
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Hi Gary,
This does not patch cleanly for me (PPCISelLowering.cpp). Can you
prepare a updated patch?
Thanks,
Evan
On Jul 10, 2008, at 11:45 AM, Gary Benson wrote:
> Cool, that worked. New patch attached...
>
> Cheers,
> Gary
>
> Evan Cheng wrote:
>> Just cast both values to const TargetRegisterClass*.
>>
>> Evan
>>
>> On Jul 10, 2008, at 7:36
2008 Jul 10
0
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Just cast both values to const TargetRegisterClass*.
Evan
On Jul 10, 2008, at 7:36 AM, Gary Benson wrote:
> Evan Cheng wrote:
>> How about?
>>
>> const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass :
>> &PPC:G8RCRegClass;
>> unsigned TmpReg = RegInfo.createVirtualRegister(RC);
>
> I tried something like that yesterday:
>
> const
2008 Jul 10
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Evan Cheng wrote:
> How about?
>
> const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass :
> &PPC:G8RCRegClass;
> unsigned TmpReg = RegInfo.createVirtualRegister(RC);
I tried something like that yesterday:
const TargetRegisterClass *RC =
is64bit ? &PPC::GPRCRegClass : &PPC::G8RCRegClass;
but I kept getting this error no matter how I arranged it:
2008 Jun 30
0
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
You need to insert new basic blocks and update CFG to accomplish this.
There is a hackish way to do this right now. Add a pseudo instruction
to represent this operation and mark it usesCustomDAGSchedInserter.
This means the intrinsic is mapped to a single (pseudo) node. But it
is then expanded into instructions that can span multiple basic
blocks. See
2008 Jul 08
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Would it be acceptable to change MachineInstr::getRegInfo from private
to public so I can use it from PPCTargetLowering::EmitInstrWithCustomInserter?
Cheers,
Gary
Evan Cheng wrote:
> Look for createVirtualRegister. These are examples in
> PPCISelLowering.cpp.
>
> Evan
> On Jul 8, 2008, at 8:24 AM, Gary Benson wrote:
>
> > Hi Evan,
> >
> > Evan Cheng wrote:
2008 Jun 30
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Chris Lattner wrote:
> On Jun 27, 2008, at 8:27 AM, Gary Benson wrote:
> > def CMP_UNRESw : Pseudo<(outs), (ins GPRC:$rA, GPRC:$rB, i32imm:
> > $label),
> > "cmpw $rA, $rB\n\tbne- La${label}_exit",
> > [(PPCcmp_unres GPRC:$rA, GPRC:$rB, imm:
> > $label)]>;
> > }
> >
> > ...and
2016 Jul 29
2
Help with ISEL matching for an SDAG
I have the following selection DAG:
SelectionDAG has 9 nodes:
t0: ch = EntryToken
t2: i64,ch = CopyFromReg t0, Register:i64 %vreg0
t16: i32,ch = load<LD1[%ptr](tbaa=<0x10023c9f448>), anyext from i8> t0,
t2, undef:i64
t15: v16i8 = BUILD_VECTOR t16, t16, t16, t16, t16, t16, t16, t16, t16,
t16, t16, t16, t16, t16, t16, t16
t11: ch,glue = CopyToReg t0, Register:v16i8 %V2, t15
2008 Jul 10
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Cool, that worked. New patch attached...
Cheers,
Gary
Evan Cheng wrote:
> Just cast both values to const TargetRegisterClass*.
>
> Evan
>
> On Jul 10, 2008, at 7:36 AM, Gary Benson wrote:
> > Evan Cheng wrote:
> > > How about?
> > >
> > > const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass :
> > > &PPC:G8RCRegClass;
>
2010 Jun 11
2
[LLVMdev] r98938 broke argument passing on MSP430?
Hello,
Yesterday I noticed that MSP430 argument passing is broken in trunk;
see http://llvm.org/PR6573 for details and testcases. The problem is
that calls aren't being preceded by instructions that put the
arguments into registers. I backtracked my working copy and then
stepped forward until it broke between r98937 and r98938. Refining
further, I found that rolling back the
2019 Nov 20
4
Tablegen PAT limitation?
Hi,
The full trace stack:
Type set is empty for each HW mode:
possible type contradiction in the pattern below (use -print-records with llvm-tblgen to see all expanded records).
vtInt: (vt:{ *:[Other] })
UNREACHABLE executed at /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:824!
[ 85%] Building X86GenEVEX2VEXTables.inc...
#0 0x000000000081b9b5
2019 Nov 21
2
Tablegen PAT limitation?
Hi Krzysztof,
Today I try it on llvm9.0.0 version.
def bos : RPPInstMMEMrr<OPC_STORE,
(outs), (ins MGPR:$rs1, SGPR32:$rbase, MGPR:$roffset, uimm2:$rshift),
!strconcat(opcodestr, ""), "$rs1,
2019 Nov 22
2
Tablegen PAT limitation?
def STOREbos { // InstructionEncoding Instruction RPPInst RPPInstMMEMrr
field bits<32> Inst = { 0, 0, 0, 1, rs1{2}, rs1{1}, rs1{0}, index{0}, 0, 0, 0, 1, 0, rbase{3}, rbase{2}, rbase{1}, rbase{0}, rbase{4}, roffset{4}, roffset{3}, roffset{2}, roffset{1}, roffset{0}, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
field bits<32> SoftFail = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,