Displaying 20 results from an estimated 600 matches similar to: "[LLVMdev] Emitting PPC branches"
2008 Jun 27
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Hi all,
I'm trying to figure out how to add the instructions required for
llvm.atomic.cmp.swap.i32 on PowerPC. I figured out LWARX (patch
attached) but the other two (CMP_UNRESw and STWCX) require multiple
instructions:
let Defs = [CR0] in {
def STWCX : Pseudo<(outs), (ins GPRC:$rS, memrr:$dst, i32imm:$label),
"stwcx. $rS, $dst\n\tbne-
2008 Jul 08
3
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Hi Evan,
Evan Cheng wrote:
> The patch looks great. But I do have one comment:
>
> +let usesCustomDAGSchedInserter = 1 in {
> + let Uses = [CR0] in {
> + let Uses = [R0] in
> + def ATOMIC_LOAD_ADD_I32 : Pseudo<
>
> The "let Uses = [R0]" is not needed. The pseudo instruction will be
> expanded like this later:
>
> + BuildMI(BB,
2008 Jul 08
0
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
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:
>> The patch looks great. But I do have one comment:
>>
>> +let usesCustomDAGSchedInserter = 1 in {
>> + let Uses = [CR0] in {
>> + let Uses = [R0] in
>> + def ATOMIC_LOAD_ADD_I32 :
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 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
>
2008 Jul 04
0
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Hi Gary,
The patch looks great. But I do have one comment:
+let usesCustomDAGSchedInserter = 1 in {
+ let Uses = [CR0] in {
+ let Uses = [R0] in
+ def ATOMIC_LOAD_ADD_I32 : Pseudo<
The "let Uses = [R0]" is not needed. The pseudo instruction will be
expanded like this later:
+ BuildMI(BB, TII->get(is64bit ? PPC::LDARX : PPC::LWARX), dest)
+
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 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 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 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 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 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:
2020 Jul 06
0
[PATCH v3 3/6] powerpc: move spinlock implementation to simple_spinlock
To prepare for queued spinlocks. This is a simple rename except to update
preprocessor guard name and a file reference.
Signed-off-by: Nicholas Piggin <npiggin at gmail.com>
---
arch/powerpc/include/asm/simple_spinlock.h | 292 ++++++++++++++++++
.../include/asm/simple_spinlock_types.h | 21 ++
arch/powerpc/include/asm/spinlock.h | 285 +----------------
2008 Jun 27
0
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Hello, Gary
> I'm trying to figure out how to add the instructions required for
> llvm.atomic.cmp.swap.i32 on PowerPC. I figured out LWARX (patch
> attached)
Applied, thanks!
> but the other two (CMP_UNRESw and STWCX) require multiple
> instructions:
>
> let Defs = [CR0] in {
> def STWCX : Pseudo<(outs), (ins GPRC:$rS, memrr:$dst, i32imm:$label),
>
2011 Oct 22
0
[LLVMdev] Instruction Scheduling Itineraries
On Oct 21, 2011, at 12:15 AM, James Molloy wrote:
> Hi Andy,
>
> Could you describe how this would be done? In the current ARM itineraries
> (say C-A9 for example), the superscalar issue stage is modelled as taking 1
> cycle. If it were to take 2 cycles instead, as far as I can tell the hazard
> analyser would stall because both FU's would be acquired.
>
> I would
2020 Jul 03
7
[PATCH v2 0/6] powerpc: queued spinlocks and rwlocks
v2 is updated to account for feedback from Will, Peter, and
Waiman (thank you), and trims off a couple of RFC and unrelated
patches.
Thanks,
Nick
Nicholas Piggin (6):
powerpc/powernv: must include hvcall.h to get PAPR defines
powerpc/pseries: move some PAPR paravirt functions to their own file
powerpc: move spinlock implementation to simple_spinlock
powerpc/64s: implement queued
2020 Jul 24
8
[PATCH v4 0/6] powerpc: queued spinlocks and rwlocks
Updated with everybody's feedback (thanks all), and more performance
results.
What I've found is I might have been measuring the worst load point for
the paravirt case, and by looking at a range of loads it's clear that
queued spinlocks are overall better even on PV, doubly so when you look
at the generally much improved worst case latencies.
I have defaulted it to N even though