search for: i123

Displaying 6 results from an estimated 6 matches for "i123".

Did you mean: 123
2008 Oct 26
6
[LLVMdev] Turning on LegalizeTypes by default
...fault tomorrow. This is a redesign/reimplementation of the logic currently in LegalizeDAG that turns (for example) 64 bit arithmetic on a 32 bit machine into a series of 32 bit operations. As well as being a cleaner design, it also supports code generation for arbitrary precision integers such as i123. This is likely to cause some breakage since I mostly only added support for operations for which I had a testcase (by running "make check" or compiling the testsuite etc), and I was only able to test on x86 linux (32 and 64 bit). However it is usually easy to add support for missing op...
2008 Oct 28
0
[LLVMdev] Turning on LegalizeTypes by default
...s is a redesign/reimplementation > of the logic currently in LegalizeDAG that turns (for example) 64 bit > arithmetic on a 32 bit machine into a series of 32 bit operations. As well > as being a cleaner design, it also supports code generation for arbitrary > precision integers such as i123. You state that it properly lowers higher bit mathematics and odd precision ints on systems. Will it handle, say, an i1097 on an x86 system, by lowering it to high precision math, or will it ignore it and have the compile fail as normal?
2010 Sep 29
0
[LLVMdev] spilling & xmm register usage
...float %tmp7.i94.i, %tmp30.i117.i > %tmp32.i119.i = fadd float %tmp31.i118.i, 0x3FFC80EF00000000 > %tmp33.i120.i = fmul float %tmp7.i94.i, %tmp32.i119.i > %tmp34.i121.i = fadd float %tmp33.i120.i, 0xBFD6D1F0E0000000 > %tmp35.i122.i = fmul float %tmp7.i94.i, %tmp34.i121.i > %tmp36.i123.i = fadd float %tmp35.i122.i, 0x3FD470BF40000000 > %tmp37.i124.i = fmul float %tmp19.i106.i, %tmp36.i123.i > %tmp38.i125.i = fsub float 1.000000e+00, %tmp37.i124.i > %cmp.i128.i = fcmp olt float %tmp11.i.i, 0.000000e+00 > br i1 %cmp.i128.i, label %cond.then.i132.i, label %phi.exit13...
2010 Sep 29
3
[LLVMdev] spilling & xmm register usage
Hello everybody, I have stumbled upon a test case (the attached module is a slightly reduced version) that shows extremely reduced performance on linux compared to windows when executed using LLVM's JIT. We narrowed the problem down to the actual code being generated, the source IR on both systems is the same. Try compiling the attached module: llc -O3 -filetype=asm -o BAD.s BAD.ll Under
2008 Oct 26
0
[LLVMdev] Turning on LegalizeTypes by default
...; reimplementation > of the logic currently in LegalizeDAG that turns (for example) 64 bit > arithmetic on a 32 bit machine into a series of 32 bit operations. > As well > as being a cleaner design, it also supports code generation for > arbitrary > precision integers such as i123. Woo hoo! > So please: if LegalizeTypes breaks something, send me a bitcode > testcase > rather than turning LegalizeTypes off again. With a major change > like this > there is bound to be some pain, but I don't expect it to last more > than a > week or two. Makes...
2013 Feb 14
1
[LLVMdev] LiveIntervals analysis problem
...32 0, i32 11 %arrayidx26.10.i = getelementptr inbounds [14 x i16]* %tprod, i32 0, i32 12 %incdec.ptr2.1.i117 = getelementptr inbounds i16* %num, i32 4 %incdec.ptr2.2.i119 = getelementptr inbounds i16* %num, i32 5 %incdec.ptr2.3.i121 = getelementptr inbounds i16* %num, i32 6 %incdec.ptr2.4.i123 = getelementptr inbounds i16* %num, i32 7 %incdec.ptr2.5.i125 = getelementptr inbounds i16* %num, i32 8 %incdec.ptr2.6.i127 = getelementptr inbounds i16* %num, i32 9 %incdec.ptr2.7.i129 = getelementptr inbounds i16* %num, i32 10 %incdec.ptr2.8.i131 = getelementptr inbounds i16* %num, i32 11...