search for: r54

Revision: 54 Author: freyfogle Date: Fri Nov 6 07:21:27 2009 Log: Marker should pass in google MarkerImage objects rather than just image URLs if possible http://code.google.com/p/mapstraction/source/detail?r=54 Modified: /trunk/source/mxn.googlev3.core.js ======================================= --- /trunk/source/mxn.googlev3.core.js Fri Oct 9 07:48:43 2009 +++

...k sorts operands of commutative SCEVs by their getSCEVType() value, and then does an ad-hoc sort to group repeated operands, but it does not do a full sort. In some test cases I'm looking at right now, this causes it to miss opportunities to reuse SCEV objects, as in cases like this: ( %i + %r54 + %r59) ( %r54 + %r59 + %i) As a result, passes like LoopStrengthReduce which use addresses of SCEVs as keys in std::map end up using different entries for these. The obvious solution would be to sort the values. Many SCEV types could be ordered in reasonable ways, though for SCEVUnknown it w...

...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 %r56 %r44 (0) Constantfolding... MAIN:-1 () BB:0 (14 instructions) - df = { } -> BB:1 (tree) 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: mov f...

...ive SCEVs by their > getSCEVType() value, and then does an ad-hoc sort to group repeated > operands, but it does not do a full sort. In some test cases I'm > looking at right now, this causes it to miss opportunities to reuse > SCEV objects, as in cases like this: > > ( %i + %r54 + %r59) > ( %r54 + %r59 + %i) > > As a result, passes like LoopStrengthReduce which use addresses of > SCEVs as keys in std::map end up using different entries for these. Ouch. :( > The obvious solution would be to sort the values. Many SCEV types could > be ordered in reas...

...32 %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 %r56 %r44 (0) > > Constantfolding... > > MAIN:-1 () > BB:0 (14 instructions) - df = { } > -> BB:1 (tree) > 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...

...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 %r56 %r44 (0) >> >> Constantfolding... >> >> MAIN:-1 () >> BB:0 (14 instructions) - df = { } >> -> BB:1 (tree) >> 0: nop u32 %r56 (0) >> 1: ld u32 %r31 c0[0x0] (0) >> 2: ld u32 %r37 c0[0x...

...tion call 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...

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

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

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

...snappy-c = 836415 us ( 253 MB/s) 300567 us ( 705 MB/s) 211957760 -> 131060567 61.8% lzo 2.06 1x_1 = 639305 us ( 331 MB/s) 470840 us ( 450 MB/s) 211957760 -> 100576151 47.5% * snappy 1.0.4 svn r58 * snappy-c as Andi sent it to mailinglist * lzo 2.0.6 1x_1 variant * lz4 r55 (r54 + bugfix in the hash table entry type) * compiled by gcc 4.7, -O2 pullable from: git://repo.or.cz/linux-2.6/btrfs-unstable.git dev/compression-squad david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org Mo...