Displaying 5 results from an estimated 5 matches for "cmplw".
Did you mean:
cmpl
2004 Oct 06
3
flac-1.1.1 completely broken on linux/ppc and on macosx if built with the standard toolchain (not xcode)
Sadly the latest optimization broke completely everything.
The asm code isn't gas compliant. the libFLAC linker script has a typo,
disabling the asm optimization and/or altivec won't let a correct build
anyway.
Instant fixes for the asm stuff:
sed -i -e"s:;:\#:" on the lpc_asm.s
to load address instead of addis+ori you could use
lis and la and PLEASE use the @l(register)
2004 Sep 10
1
altivec lpc_restore_signal
...addi r9,r1,-28
li r31,0xf
andc r9,r9,r31 ; for quadword-aligned stack data
slwi r6,r6,2 ; adjust for word size
slwi r4,r4,2
add r4,r4,r8 ; r4 = data+data_len
mfspr r0,256 ; cache old vrsave
addis r31,0,hi16(0xfffffc00)
ori r31,r31,lo16(0xfffffc00)
mtspr 256,r31 ; declare VRs in vrsave
cmplw cr0,r8,r4 ; i<data_len
bc 4,0,L1400
; load coefficients into v0-v7 and initial history into v8-v15
li r31,0xf
and r31,r8,r31 ; r31: data%4
li r11,16
subf r31,r31,r11 ; r31: 4-(data%4)
slwi r31,r31,3 ; convert to bits for vsro
li r10,-4
stw r31,-4(r9)
lvewx v0,r10,r9
vspltisb v18,-1...
2004 May 17
2
[LLVMdev] Testing LLVM on OS X
...8_tmp_2E_180 > l8_mem_tmp_2E_0) ?
(4294967295u) : (0u))) + l8_chain_length_2E_1;
.. some other code ...
l13_loopcont_2E_0:
if (l8_tmp_2E_180 > l8_mem_tmp_2E_0) {
goto l13_shortcirc_next_2E_11;
} else {
goto l13_UnifiedReturnBlock;
}
then the assembly generated becomes a cmplw and branch where it occurs.
Making this change in only this one spot causes the time to run to
decrease 69 seconds, giving it a speedup of 6% from the 5/12 LLVM CVS.
I noticed several spots in the CBE code where this type of code was
generated, and if it was changed to emit code the 2nd way it...
2004 May 09
0
[LLVMdev] Testing LLVM on OS X
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
2004 May 04
6
[LLVMdev] Testing LLVM on OS X
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 going on.
I took this very simple C function:
int Array[1000];
void test(int