Displaying 14 results from an estimated 14 matches for "r56".
Did you mean:
256
2016 Oct 02
2
[PATCH] nv50/ir: Propagate third immediate src when folding OP_MAD
...t; matter, the mov's should get cleaned up. [Clearly 17 shaders
> disagree...] Is this just a side-effect of the fact that we don't run
> the opts to a fixed point?
It is a second mov that causes a problem for later folding in the imm,
here output of a testshader[1]:
0: nop u32 %r56 (0)
1: ld u32 %r31 c0[0x0] (0)
2: ld u32 %r37 c0[0x140] (0)
3: mov u32 %r38 0x00000000 (0)
4: mov u32 %r39 0x3f800000 (0)
5: mad f32 %r40 %r37 %r38 %r39 (0)
6: mad f32 %r44 %r37 %r38 %r38 (0)
7: add f32 %r53 %r31 %r40 (0)
8: add f32 %r54 %r31 %r44 (0)
9: add f32 %r57 %r...
2016 Oct 02
0
[PATCH] nv50/ir: Propagate third immediate src when folding OP_MAD
...t cleaned up. [Clearly 17 shaders
>> disagree...] Is this just a side-effect of the fact that we don't run
>> the opts to a fixed point?
>
>
> It is a second mov that causes a problem for later folding in the imm, here
> output of a testshader[1]:
>
> 0: nop u32 %r56 (0)
> 1: ld u32 %r31 c0[0x0] (0)
> 2: ld u32 %r37 c0[0x140] (0)
> 3: mov u32 %r38 0x00000000 (0)
> 4: mov u32 %r39 0x3f800000 (0)
> 5: mad f32 %r40 %r37 %r38 %r39 (0)
> 6: mad f32 %r44 %r37 %r38 %r38 (0)
> 7: add f32 %r53 %r31 %r40 (0)
> 8: add f32 %r54 %r3...
2016 Oct 02
1
[PATCH] nv50/ir: Propagate third immediate src when folding OP_MAD
...7 shaders
>>> disagree...] Is this just a side-effect of the fact that we don't run
>>> the opts to a fixed point?
>>
>> It is a second mov that causes a problem for later folding in the imm, here
>> output of a testshader[1]:
>>
>> 0: nop u32 %r56 (0)
>> 1: ld u32 %r31 c0[0x0] (0)
>> 2: ld u32 %r37 c0[0x140] (0)
>> 3: mov u32 %r38 0x00000000 (0)
>> 4: mov u32 %r39 0x3f800000 (0)
>> 5: mad f32 %r40 %r37 %r38 %r39 (0)
>> 6: mad f32 %r44 %r37 %r38 %r38 (0)
>> 7: add f32 %r53 %r31...
2016 Oct 02
2
[PATCH] nv50/ir: Propagate third immediate src when folding OP_MAD
Previously we'd end up with an unnecessary mov for the thirs immediate value.
total instructions in shared programs : 851881 -> 851864 (-0.00%)
total gprs used in shared programs : 110295 -> 110295 (0.00%)
total local used in shared programs : 1020 -> 1020 (0.00%)
local gpr inst bytes
helped 0 0 17 17
2010 Jun 15
0
[LLVMdev] Question on X86 backend
...let isCall = 1,
Defs = [
R0, R1, R2, R3, R4, R5, R6, R7, R8, R9, R10, R11, R12, R13, R14, R15,
R16, R17, R18, R19, R20, R21, R22, R23, R24, R25, R26, R27, R28, R29, R30, R31,
R32, R33, R34, R35, R36, R37, R38, R39, R40, R41, R42, R43, R44, R45, R46, R47,
R48, R49, R50, R51, R52, R53, R54, R55, R56, R57, R58, R59, R60, R61, R62, R63,
R64, R65, R66, R67, R68, R69, R70, R71, R72, R73, R74, R75, R76, R77, R78, R79,
R80, R81, R82, R83, R84, R85, R86, R87, R88, R89, R90, R91, R92, R93, R94, R95,
R96, R97, R98, R99, R100, R101, R102, R103, R104, R105, R106, R107, R108, R109, R110, R111,
R112, R...
2010 Jun 15
2
[LLVMdev] Question on X86 backend
Hi Micah,
> In X86InstrInfo.td for Call Instructions, it mentions that Uses for
> argument registers are added manually. Can someone point me to the
> location where they are added as the comment doesn't reference a
> where or how?
the register uses are added by the function
X86TargetLowering::LowerCall() during the DAG Lowering phase. This is
the relevant code segment:
// Add
2016 Apr 08
2
[PATCH mesa v2 1/2] nouveau: codegen: Use FILE_MEMORY_BUFFER for buffers
...) - df = { }
-> BB:1 (tree)
0: mov u32 %r1 0x00000000 (0)
1: ld u32 %r0 b[0x0] (0)
2: presin f32 %r3 %r0 (0)
3: cos f32 %r3 %r3 (0)
4: mov u32 %r2 %r3 (0)
...
And after the first lowering step:
MAIN:-1 ()
BB:0 (77 instructions) - df = { }
-> BB:1 (tree)
0: mov u32 %r56 0x00000000 (0)
1: ld u64 %r57d c15[0x300] (0)
2: mov u32 %r58 0x00000004 (0)
3: ld u32 %r59 c15[0x308] (0)
4: set u8 %p60 gt u32 %r58 %r59 (0)
5: mov u32 %r61 0x00000000 (0)
6: not %p60 ld u32 %r62 g[%r57d+0x0] (0)
...
Note how the 'b' printing is only used before t...
2016 Apr 12
2
[PATCH mesa v2 1/2] nouveau: codegen: Use FILE_MEMORY_BUFFER for buffers
...t;> 2: presin f32 %r3 %r0 (0)
>> 3: cos f32 %r3 %r3 (0)
>> 4: mov u32 %r2 %r3 (0)
>> ...
>>
>> And after the first lowering step:
>>
>> MAIN:-1 ()
>> BB:0 (77 instructions) - df = { }
>> -> BB:1 (tree)
>> 0: mov u32 %r56 0x00000000 (0)
>> 1: ld u64 %r57d c15[0x300] (0)
>> 2: mov u32 %r58 0x00000004 (0)
>> 3: ld u32 %r59 c15[0x308] (0)
>> 4: set u8 %p60 gt u32 %r58 %r59 (0)
>> 5: mov u32 %r61 0x00000000 (0)
>> 6: not %p60 ld u32 %r62 g[%r57d+0x0] (0)
>>...
2006 Feb 24
2
r56 - trunk/debian
Author: tha-guest
Date: 2006-02-24 23:45:10 +0000 (Fri, 24 Feb 2006)
New Revision: 56
Modified:
trunk/debian/README.Debian
trunk/debian/changelog
trunk/debian/control
trunk/debian/linux-2.6.12-xen.patch
Log:
hopefully for the last commit before release ;-P
- xen-hypervisor & -pae now recommends grub (besides PXE-Boot there is no alternative)
- updated & added some more to
2016 Apr 08
0
[PATCH mesa v2 1/2] nouveau: codegen: Use FILE_MEMORY_BUFFER for buffers
...000 (0)
> 1: ld u32 %r0 b[0x0] (0)
> 2: presin f32 %r3 %r0 (0)
> 3: cos f32 %r3 %r3 (0)
> 4: mov u32 %r2 %r3 (0)
> ...
>
> And after the first lowering step:
>
> MAIN:-1 ()
> BB:0 (77 instructions) - df = { }
> -> BB:1 (tree)
> 0: mov u32 %r56 0x00000000 (0)
> 1: ld u64 %r57d c15[0x300] (0)
> 2: mov u32 %r58 0x00000004 (0)
> 3: ld u32 %r59 c15[0x308] (0)
> 4: set u8 %p60 gt u32 %r58 %r59 (0)
> 5: mov u32 %r61 0x00000000 (0)
> 6: not %p60 ld u32 %r62 g[%r57d+0x0] (0)
> ...
>
> Note how th...
2015 Jun 07
43
[Bug 90887] New: PhiMovesPass in register allocator broken
https://bugs.freedesktop.org/show_bug.cgi?id=90887
Bug ID: 90887
Summary: PhiMovesPass in register allocator broken
Product: Mesa
Version: git
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/DRI/nouveau
Assignee: nouveau at
2016 Apr 14
0
[PATCH mesa v2 1/2] nouveau: codegen: Use FILE_MEMORY_BUFFER for buffers
...>> 3: cos f32 %r3 %r3 (0)
>>> 4: mov u32 %r2 %r3 (0)
>>> ...
>>>
>>> And after the first lowering step:
>>>
>>> MAIN:-1 ()
>>> BB:0 (77 instructions) - df = { }
>>> -> BB:1 (tree)
>>> 0: mov u32 %r56 0x00000000 (0)
>>> 1: ld u64 %r57d c15[0x300] (0)
>>> 2: mov u32 %r58 0x00000004 (0)
>>> 3: ld u32 %r59 c15[0x308] (0)
>>> 4: set u8 %p60 gt u32 %r58 %r59 (0)
>>> 5: mov u32 %r61 0x00000000 (0)
>>> 6: not %p60 ld u32 %r62 g[...
2016 Mar 17
4
[PATCH mesa v2 1/2] nouveau: codegen: Use FILE_MEMORY_BUFFER for buffers
Some of the lowering steps we currently do for FILE_MEMORY_GLOBAL only
apply to buffers, making it impossible to use FILE_MEMORY_GLOBAL for
OpenCL global buffers.
This commits changes the buffer code to use FILE_MEMORY_BUFFER at the
ir_from_tgsi and lowering steps, freeing use of FILE_MEMORY_GLOBAL
for use with OpenCL global buffers.
Note that after lowering buffer accesses use the
2008 Jun 30
4
Rebuild of kernel 2.6.9-67.0.20.EL failure
Hello list.
I'm trying to rebuild the 2.6.9.67.0.20.EL kernel, but it fails even without
modifications.
How did I try it?
Created a (non-root) build environment (not a mock )
Installed the kernel.scr.rpm and did a
rpmbuild -ba --target=`uname -m` kernel-2.6.spec 2> prep-err.log | tee
prep-out.log
The build failed at the end:
Processing files: kernel-xenU-devel-2.6.9-67.0.20.EL
Checking