search for: r62

...? :) I don't think it's undefined behavior. Right before instcombine, we have this: %r60 = load <2 x i64>* %"$LCS_1", align 16 ; <<2 x i64>> [#uses=2] ; srcLine 41 %r61 = extractelement <2 x i64> %r60, i32 0 ; <i64> [#uses=1] ; srcLine 41 %r62 = getelementptr <2 x double>* null, i32 0, i64 %r61 ; <double*> [#uses=1] ; srcLine 41 %r63 = load double* %r62 ; <double> [#uses=1] ; srcLine 41 So we're loading a vector of pointers and then using getelementptr as basically a reg-reg copy with a cast (I think). Yes,...

...t's undefined behavior. Right before instcombine, we have > this: > > %r60 = load <2 x i64>* %"$LCS_1", align 16 ; <<2 x i64>> [#uses=2] ; > srcLine 41 > %r61 = extractelement <2 x i64> %r60, i32 0 ; <i64> [#uses=1] ; srcLine > 41 %r62 = getelementptr <2 x double>* null, i32 0, i64 %r61 ; <double*> > [#uses=1] ; srcLine 41 > %r63 = load double* %r62 ; <double> [#uses=1] ; srcLine 41 > > So we're loading a vector of pointers and then using getelementptr as > basically a reg-reg copy with a...

On Fri, 4 Apr 2008, David Greene wrote: > I am confused by this bit of code in instcombine: > > 09789 if (GetElementPtrInst *GEPI = dyn_cast<GetElementPtrInst>(Op)) { > 09790 const Value *GEPI0 = GEPI->getOperand(0); > 09791 // TODO: Consider a target hook for valid address spaces for this > xform. > 09792 if (isa<ConstantPointerNull>(GEPI0)

I am confused by this bit of code in instcombine: 09789 if (GetElementPtrInst *GEPI = dyn_cast<GetElementPtrInst>(Op)) { 09790 const Value *GEPI0 = GEPI->getOperand(0); 09791 // TODO: Consider a target hook for valid address spaces for this xform. 09792 if (isa<ConstantPointerNull>(GEPI0) && 09793

...grid(c("R11", "R12", "R13"), c("R21", "R22", "R23"), c("R31", "R32", "R33"), c("R41", "R42", "R43"), c("R51", "R52", "R53"), c("R61", "R62", "R63"), c("R71", "R72", "R73"), c("R81", "R82", "R83"),  c("R91", "R92", "R93"), c("R101", "R102", "R103"))   range_prob <- list() range_prob[[1]]  <- c(0.4...

...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, R113, R114, R115, R116, R117, R...

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

A non-text attachment was scrubbed... Name: not available Type: text Size: 997 bytes Desc: not available Url : https://stat.ethz.ch/pipermail/r-help/attachments/19980618/ee08ba8d/attachment.pl

...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 the buffer access is lowered to a global access, so this seems to be the right thing todo. Regards, Hans > >> case FILE_MEMORY_GLOBAL: c = 'g'; break; >> case FILE_MEMORY_SHARED: c =...

...e) >> 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 the buffer access >> is lowered to a global access, so this seems to be the right thing todo. >> > > Fine by me. > Thanks. > >> Regards, >> >> Hans >...

...= { } > -> 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 the buffer access > is lowered to a global access, so this seems to be the right thing todo. > Fine by me. Thanks. > Regards, > > Hans > > >> >>> case FILE_MEMORY_...

...2 %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 the buffer access >>> is lowered to a global access, so this seems to be the right thing todo. >>> >> >> Fine by me. >> Thanks. >> >>&...

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

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