search for: r18

Hi. The patch I send before was too large so that it was dropped from the maling list. I'm sending again with smaller size. This patch set is the xen paravirtualization of hand written assenbly code. And I expect that much clean up is necessary before merge. We really need the feed back before starting actual clean up as Eddie already said before. Eddie discussed how to clean up and suggested

Hi. The patch I send before was too large so that it was dropped from the maling list. I'm sending again with smaller size. This patch set is the xen paravirtualization of hand written assenbly code. And I expect that much clean up is necessary before merge. We really need the feed back before starting actual clean up as Eddie already said before. Eddie discussed how to clean up and suggested

...S | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/ia64/kernel/ivt.S b/arch/ia64/kernel/ivt.S index 416a952..f675d8e 100644 --- a/arch/ia64/kernel/ivt.S +++ b/arch/ia64/kernel/ivt.S @@ -580,7 +580,7 @@ ENTRY(dirty_bit) mov b0=r29 // restore b0 ;; st8 [r17]=r18 // store back updated PTE - itc.d r18 // install updated PTE + ITC_D(p0, r18, r16) // install updated PTE #endif mov pr=r31,-1 // restore pr RFI @@ -646,7 +646,7 @@ ENTRY(iaccess_bit) mov b0=r29 // restore b0 ;; st8 [r17]=r18 // store back updated PTE - itc.i r18 // i...

...in two contiguous 8 bit regs being the low part an even reg? Remember data would be expanded into 8 bit ops, so when we're working with dags after type legalization do we really know the original type before expansion? As an example, storing a short in r21:r20 would be valid, but r20:r19 or r20:r18 would be invalid because the in the first case the low reg is odd and in the second case regs arent contiguous. To store data wider than 16 bits, for example for a 32 bit int we would use 2 register pairs (4 8bit regs) but here the pairs dont need to be contiguous so storing it r25:r24:r19:r18 is c...

Hi Borja, > Without doing what i mentioned and letting LLVM expand all operations wider > than 8 bits as you asked, the code produced is excellent supposing that many > of the moves there should be 16 bit moves reducing code size and right > register allocation, also something important for me is that the code is > better than gcc's. When i say right reg allocation it doesnt

...actly why i need the constraints and how to combine instructions. typedef short t; extern t mcos(t a); extern t mdiv(t a, t b); t foo(t a, t b) { short p1 = mcos(b); short p2 = mcos(a); return mdiv(p1&p2, p1^p2); } This C code produces: ; a<- r25:r24 b<--r23:r22 mov r18, r24 mov r19, r25 <-- can be combined into a movw r19:r18, r25:r24 mov r25, r23 mov r24, r22 <-- can be combined into a movw r25:r24, r23:r22 call mcos ; here we have the case i was explaining, pairs dont match because they're the other way round, function resu...

Hi. I rewrote the patch according to the comments. I adopted generating in-place code because it looks the quickest way. The point Eddie wanted to discuss is how to generate code and its ABI. i.e. in-place generating v.s. direct jump v.s. indirect function call Indirect function call doesn't make sense because ivt.S is compiled multi times. And it is up to pv instances to choose in-place

Hi. I rewrote the patch according to the comments. I adopted generating in-place code because it looks the quickest way. The point Eddie wanted to discuss is how to generate code and its ABI. i.e. in-place generating v.s. direct jump v.s. indirect function call Indirect function call doesn't make sense because ivt.S is compiled multi times. And it is up to pv instances to choose in-place

...lude/llvm/CodeGen/MachineInstrBuilder.h:435 #6 ... in llvm::finalizeBundle (MBB=..., FirstMI=..., LastMI=...) at ...lib/CodeGen/MachineInstrBundle.cpp:112 Let me give you another example though. I have the following existing bundle: v BUNDLE %R0<imp-def,dead>, %PC<imp-def>, %R18<imp-use> *^v %R0<def> = AND_ri %R18, 128 *^ JMP_EQriPnt_nv_V4 %R0<kill,internal>, 0, <BB#2>, %PC<imp-def> I need to move an instruction into this bundle from another location and insert it _between_ AND_ri and JMP_EQriPnt_nv_V4. I use MBB->splice(...) to do...

...rted a new one. In this case you should either erase the old BUNDLE first, or unbundle it from the instructions you are trying to finalize. > Let me give you another example though. I have the following existing > bundle: > > v BUNDLE %R0<imp-def,dead>, %PC<imp-def>, %R18<imp-use> > *^v %R0<def> = AND_ri %R18, 128 > *^ JMP_EQriPnt_nv_V4 %R0<kill,internal>, 0, <BB#2>, %PC<imp-def> > > I need to move an instruction into this bundle from another location and > insert it _between_ AND_ri and JMP_EQriPnt_nv_V4. I use MBB...

...vement, this instruction can move register pairs in a single cycle, doing something like this: mov r25, r23 mov r24, r22 into: movw r25:r24, r23:r22 The key point here is that the movw instruction can only move data of fixed pairs in this way. movw Rdest+1:Rdest, Rorig+1:Rorig, so movw R25:R23, R21:R18 is illegal because registers pairs aren't adjacent. Explaining this as if it was for x86 may make things more clear. Suppose we only have 8bit regs (ah, al, cl, ch, bl, bh, etc...) with 8 bit instructions and a few 16 bit instrs that only work with ax, bx, cx,.... We could pair ah:al to form a...

...ber of 16-bit instructions. [...] > typedef unsigned short t; > t foo(t a, t b, t c) > { > return a+b; > } [...] > This is fine until we get to the register allocation stage, there it does: > BB#0: derived from LLVM BB %entry > Live Ins: %R25R24 %R23R22 > %R18<def> = COPY %R24 > %R19<def> = COPY %R25 > %R24<def> = COPY %R22<kill>, %R25R24<imp-def> > %R24<def> = ADDRdRr %R24, %R18<kill>, %SREG<imp-def> > %R25<def> = COPY %R23<kill> > %R25<def> = ADCRdRr %R...

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Now all the comments so far have been addressed, but only a few exceptions. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops strategy is appropriate too. Later I'll post the patchset which implements xen domU based on ia64/pv_ops.

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Now all the comments so far have been addressed, but only a few exceptions. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops strategy is appropriate too. Later I'll post the patchset which implements xen domU based on ia64/pv_ops.

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Please review and comments. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops strategy is appropriate too. Later I'll post the patchset which implements xen domU based on ia64/pv_ops. Currently only ia64/xen pv_ops implementation

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Please review and comments. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops strategy is appropriate too. Later I'll post the patchset which implements xen domU based on ia64/pv_ops. Currently only ia64/xen pv_ops implementation

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Changes from take 5 are rebased to Linux 2.6.26-rc3, bug fix ivt.S paravirtualization and multi entry point support. I believe these patches can be applied to the linux ia64 repository. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Changes from take 5 are rebased to Linux 2.6.26-rc3, bug fix ivt.S paravirtualization and multi entry point support. I believe these patches can be applied to the linux ia64 repository. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops

This code works: subset(NativeDominant.df,!ID=="37-R17") This code does not: Tree.df<-subset(NativeDominant.df,!ID==c("37-R17","37-R18","10-R1","37-R21","37-R24","R7A-R1","3-R1","37-R16")) how do i get subset() to work on a range of values? -- View this message in context: http://n4.nabble.com/subset-for-multiple-values-tp1560543p1560543.html Sent from the R help...

On Feb 1, 2013, at 3:43 PM, "Sergei Larin" <slarin at codeaurora.org> wrote: > I have a question about the following (four) asserts recently added in > bundleWithPred() and bundleWithSucc() (see below). What is the real danger > of reasserting a connection even if it already exist? The intention was to identify code that may have been converted from the old style a