Displaying 20 results from an estimated 24 matches for "sdtcisptrti".
Did you mean:
sdtcisptrty
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;
>
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
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Hi Evan,
Evan Cheng wrote:
> This does not patch cleanly for me (PPCISelLowering.cpp). Can you
> prepare a updated patch?
This should work, though I won't have access to my test box now until
next Thursday so no guarantees :)
Cheers,
Gary
--
http://gbenson.net/
-------------- next part --------------
Index: lib/Target/PowerPC/PPCISelLowering.h
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 09
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Ah, didn't see that, that's what comes of trying to do something at
5pm :) I attached an updated patch which creates a virtual register
instead of using R0. How does this look?
Cheers,
Gary
Dan Gohman wrote:
> PPCTargetLowering::EmitInstrWithCustomInserter has a reference
> to the current MachineFunction for other purposes. Can you use
> MachineFunction::getRegInfo instead?
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
2008 Jul 02
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Evan Cheng wrote:
> 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
>
2011 Apr 26
1
[LLVMdev] SDTypeProfile with negative number of operands
I noticed SDTypeProfile is commonly used with -1 for the number of
operands, as in:
def SDT_SystemZCall : SDTypeProfile<0, -1, [SDTCisPtrTy<0>]>;
What does this do?
2010 Nov 08
2
[LLVMdev] Creating tablegen patterns for intrinsics with no return value.
I have intrinsic with no return value and I need to match them to machine instructions. If the instruction has a return value I am able to correctly match it, but if I try to create some tablegen code that has no return value, the instruction gets deleted.
Here is my profile/node/pattern.
Profile:
def SDTIL_BinAtomNoRet : SDTypeProfile<0, 3, [
SDTCisPtrTy<0>, SDTCisVT<1, i32>,
2013 Apr 12
1
[LLVMdev] Problem with Store of i8 in a global address
Hi,
I am creating a new backend for a custom microcontroller.
In order to create the backend I am modifying from Mips backend.
My architecture has a store instruction with direct address mode. It
accepts two arguments: source register and address (immediate). This
instruction is not available in Mips, but it is in Hexagon, so I copied
from Hexagon the following, adapting it to my registers:
-
2016 Apr 27
2
[Sparc] builtin setjmp / longjmp - need help to get past last problem
Hi,
I'm implementing __builtin_setjmp and __builtin_longjmp for Sparc 32 bit processors (64 bit later, time allowing).
I'm basing the code on the PowerPC version, which itself is based on the X86 version.
This code is very nearly working, and I've had it working for -O0 optimisation (with a slightly different version to that below), so I know it's close.
However, the PowerPC
2010 Nov 08
0
[LLVMdev] Creating tablegen patterns for intrinsics with no return value.
On Nov 8, 2010, at 10:32 AM, Villmow, Micah wrote:
> I have intrinsic with no return value and I need to match them to machine instructions. If the instruction has a return value I am able to correctly match it, but if I try to create some tablegen code that has no return value, the instruction gets deleted.
Hi Micah,
>From your description it sounds like machine dead code elimination is
2017 Sep 19
1
Changes to 'ADJCALLSTACK*' and 'callseq_*' between LLVM v4.0 and v5.0
Hi Serge,
Thanks for your help. I have looked at the change log, and so far as I can tell, my implementation is pretty much identical to all of the in-tree targets, but I’m missing something and can’t see what it is. I have simplified my TD description to just:
def MyCallseqStart : SDNode<"ISD::CALLSEQ_START",
SDCallSeqStart<[SDTCisVT<0, i32>,
2010 Nov 08
1
[LLVMdev] Creating tablegen patterns for intrinsics with no return value.
> -----Original Message-----
> From: Jim Grosbach [mailto:grosbach at apple.com]
> Sent: Monday, November 08, 2010 10:41 AM
> To: Villmow, Micah
> Cc: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Creating tablegen patterns for intrinsics with
> no return value.
>
>
> On Nov 8, 2010, at 10:32 AM, Villmow, Micah wrote:
>
> > I have intrinsic with no
2016 Jan 07
2
TableGen error message: top-level forms in instruction pattern should have void types
I'm trying to figure out what this error message means:
error: In RelAddr: Top-level forms in instruction pattern should have void
types
The definitions it's complaining about:
//===----------------------------------------------------------------------===//
// RELADDR
//===----------------------------------------------------------------------===//
def SDT_RELADDR :
2017 Sep 15
0
Changes to 'ADJCALLSTACK*' and 'callseq_*' between LLVM v4.0 and v5.0
Hi Martin,
Pseudo CALLSEQ_START was changed in r302527, commit message contains
details on the changes.
However CALLSEQ_END was not modified. If your made changes to
ADJCALLSTACKUP to add
additional argument, that may result in error.
Thanks,
--Serge
2017-09-15 19:09 GMT+07:00 Martin J. O'Riordan via llvm-dev <
llvm-dev at lists.llvm.org>:
> Hi LLVM-Devs,
>
> I have managed