search for: r29

...ot; means "isBundledWithPred()" and "v" means "isBundledWithSucc()"): I have the following (existing) bundle for which I want to regenerate the bundle header (You see that %R17 is not currently in the def list for the bundle header). v BUNDLE %P3<imp-def>, %R29<imp-use>, %D8<imp-use,kill>, %D9<imp-use,kill>, %R6<imp-use> *^v STrid_indexed %R29, 80, %D8<kill>; mem:ST8[FixedStack2] *^v STrid_indexed %R29, 72, %D9<kill>; mem:ST8[FixedStack3] *^v %P3<def> = CMPEQri %R6, 0 *^ %R17<def> = TFR_cdnNotPt %P3<...

...)" and "v" means "isBundledWithSucc()"): > > I have the following (existing) bundle for which I want to regenerate the > bundle header (You see that %R17 is not currently in the def list for the > bundle header). > > > v BUNDLE %P3<imp-def>, %R29<imp-use>, %D8<imp-use,kill>, > %D9<imp-use,kill>, %R6<imp-use> > *^v STrid_indexed %R29, 80, %D8<kill>; mem:ST8[FixedStack2] > *^v STrid_indexed %R29, 72, %D9<kill>; mem:ST8[FixedStack3] > *^v %P3<def> = CMPEQri %R6, 0 > *^ %R17<def&g...

I see instcombine doing something I'm not sure is right. Incoming, I have this: %r29 = ptrtoint [71 x i64]* %"t$3" to i64 ; <i64> [#uses=1] %r30 = inttoptr i64 %r29 to i64* ; <i64*> [#uses=1] store i64 72057594037927936, i64* %r30, align 8 Outgoing, I have this: %r30 = getelementptr [71 x i64]* %"t$3", i32 0, i32 0 ; <i64*> [#uses=1] s...

...goto l13_shortcirc_next_2E_11; } else { goto l13_UnifiedReturnBlock; } Basically it does that check and puts the result in l2_tmp_2E_182, then uses that in the if check and the ternary thing. When this is compiled, the assembly that it generates for that check/assignment is: subc r29, r25, r2 subfe r29,r29,r29 neg r29,r29 This is pretty slow compared to just doing the check on the fly (and being able to just use a compare instruction). If I manually edit the code to change it to: l13_shortcirc_next_2E_11: l8_chain_length_2E_039 = ((l8_tmp_2E_180 > l8_mem_tmp_2E_0) ?...

Hi, Xiantao a comments is below. >+// 0x3000 Entry 12 (size 64 bundles) External Interrupt (4) >+ENTRY(kvm_interrupt) >+ mov r31=pr // prepare to save predicates >+ mov r19=12 >+ mov r29=cr.ipsr >+ ;; >+ tbit.z p6,p7=r29,IA64_PSR_VM_BIT >+ tbit.z p0,p15=r29,IA64_PSR_I_BIT >+ ;; >+(p7) br.sptk kvm_dispatch_interrupt >+ ;; >+ mov r27=ar.rsc /* M */ >+ mov r20=r1 /* A */ >+ mov r25=ar.unat /* M */ >+ mov r26=ar.pfs /* I */...

Hi, Xiantao a comments is below. >+// 0x3000 Entry 12 (size 64 bundles) External Interrupt (4) >+ENTRY(kvm_interrupt) >+ mov r31=pr // prepare to save predicates >+ mov r19=12 >+ mov r29=cr.ipsr >+ ;; >+ tbit.z p6,p7=r29,IA64_PSR_VM_BIT >+ tbit.z p0,p15=r29,IA64_PSR_I_BIT >+ ;; >+(p7) br.sptk kvm_dispatch_interrupt >+ ;; >+ mov r27=ar.rsc /* M */ >+ mov r20=r1 /* A */ >+ mov r25=ar.unat /* M */ >+ mov r26=ar.pfs /* I */...

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

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

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

..."isBundledWithSucc()"): > > > > I have the following (existing) bundle for which I want to regenerate > > the bundle header (You see that %R17 is not currently in the def list > > for the bundle header). > > > > > > v BUNDLE %P3<imp-def>, %R29<imp-use>, %D8<imp-use,kill>, > > %D9<imp-use,kill>, %R6<imp-use> *^v STrid_indexed %R29, 80, > > %D8<kill>; mem:ST8[FixedStack2] *^v STrid_indexed %R29, 72, > > %D9<kill>; mem:ST8[FixedStack3] *^v %P3<def> = CMPEQri %R6, 0 > > *^...

Jakob, 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? My problem with them happens when I try to call finalizeBundle() on an existing bundle to which I have added a new instruction. The goal - a new bundle header with liveness abbreviation, but

On Tue, 4 May 2004, Chris Lattner wrote: > On Tue, 4 May 2004, Chris Lattner wrote: > > I suspect that a large reason that LLVM does worst than a native C > > compiler with the CBE+GCC is that LLVM generates very low-level C code, > > and I'm not convinced that GCC is doing a very good job (ie, without > > syntactic loops). > > Yup, this is EXACTLY what is

...x.co.jp> --- arch/ia64/kernel/ivt.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 // stor...

...from LLVM BB %if.end Predecessors according to CFG: BB#1 %vreg61<def> = LDrih_indexed %vreg56, 3134; IntRegs:%vreg61,%vreg56 %vreg62<def> = LDriuh_indexed %vreg56, 680; IntRegs:%vreg62,%vreg56 %R1<def> = TFRI 1431655766 ADJCALLSTACKDOWN 0, %R29<imp-def>, %R30<imp-def>, %R31<imp-use>, %R30<imp-use>, %R29<imp-use> %vreg304:subreg_loreg<def,read-undef> = ADDri_SUBr_V4 %vreg62, 5, %vreg61; DoubleRegs:%vreg304 IntRegs:%vreg62,%vreg61 %vreg519<def> = TFRI 3148; IntRegs:%vreg519...

...warfRegNum<[24]>; def R25 : DLXR<25, "r25">, DwarfRegNum<[25]>; def R26 : DLXR<26, "r26">, DwarfRegNum<[26]>; def R27 : DLXR<27, "r27">, DwarfRegNum<[27]>; def R28 : DLXR<28, "r28">, DwarfRegNum<[28]>; def R29 : DLXR<29, "r29">, DwarfRegNum<[29]>; def R30 : DLXR<30, "r30">, DwarfRegNum<[30]>; def R31 : DLXR<31, "r31">, DwarfRegNum<[31]>; // Register classes def DLXRegs : RegisterClass<"DLX", [i32], 32, // Volatile [...

...12: 0x8fe71ac7 r13: 0x00000000 r14: 0x000021bc r15: 0x00000000 r16: 0xbffffcb4 r17: 0x00000001 r18: 0x00000000 r19: 0x000016d4 r20: 0x00000000 r21: 0x00000000 r22: 0x00000000 r23: 0x00000000 r24: 0x8fe4b3d8 r25: 0x00000002 r26: 0x00000002 r27: 0x00000000 r28: 0x00001610 r29: 0x00000000 r30: 0x8fe484d8 r31: 0x8fe09ecc

Several attempts to support both Mac and PCs keep failing. In my latest attempt I used the following settings: #courier-imap compatibility/Thunderbird namespace private { separator = . prefix = INBOX. inbox = yes } For MAC OS Mail.app namespace private { separator = / prefix = INBOX/ inbox = no hidden= yes } This last attempt was based on the suggestion of Timo Sirainen,

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.