search for: r225

...ut the output looks ok. There is a 8 byte sequence which does not get decoded every 64 bytes but AFAIK that is the scheduling info, so that should be fine. One thing which does stand out is that this: 0: ld u32 %r219 c0[0x0000000000000000+0x0] (0) 1: ld u32 %r222 c0[0x4] (0) 2: ld u64 { %r225 %r228 } c0[0x8] (0) 3: ld u32 %r234 c0[0x10] (0) Gets translated into (nvdisasm output) : /*0008*/ LDC R4, c[0x0][0x0]; /* 0x1400000003f11c86 */ /*0010*/ MOV R2, c[0x0][0x4]; /* 0x28004000...

...gt; not get decoded every 64 bytes but AFAIK that is the scheduling info, >> so that should be fine. >> >> One thing which does stand out is that this: >> >> 0: ld u32 %r219 c0[0x0000000000000000+0x0] (0) >> 1: ld u32 %r222 c0[0x4] (0) >> 2: ld u64 { %r225 %r228 } c0[0x8] (0) >> 3: ld u32 %r234 c0[0x10] (0) >> >> Gets translated into (nvdisasm output) : >> >> /*0008*/ LDC R4, c[0x0][0x0]; >> /* 0x1400000003f11c86 */ >> /*0010*/ MOV R2, c[0x0][0x4]; >&gt...

..., R176, R177, R178, R179, R180, R181, R182, R183, R184, R185, R186, R187, R188, R189, R190, R191, R192, R193, R194, R195, R196, R197, R198, R199, R200, R201, R202, R203, R204, R205, R206, R207, R208, R209, R210, R211, R212, R213, R214, R215, R216, R217, R218, R219, R220, R221, R222, R223, R224, R225, R226, R227, R228, R229, R230, R231, R232, R233, R234, R235, R236, R237, R238, R239, R240, R241, R242, R243, R244, R245, R246, R247, R248, R249, R250, R251, R252, R253, R254, R255 ] , Uses = [ R0, R1, R2, R3, R4, R5, R6, R7, R8, R9, R10, R11, R12, R13, R14, R15, R16, R17, R18, R19, R20, R21, R22...

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

...heduling info, >>>> so that should be fine. >>>> >>>> One thing which does stand out is that this: >>>> >>>> 0: ld u32 %r219 c0[0x0000000000000000+0x0] (0) >>>> 1: ld u32 %r222 c0[0x4] (0) >>>> 2: ld u64 { %r225 %r228 } c0[0x8] (0) >>>> 3: ld u32 %r234 c0[0x10] (0) >>>> >>>> Gets translated into (nvdisasm output) : >>>> >>>> /*0008*/ LDC R4, c[0x0][0x0]; >>>> /* 0x1400000003f11c86 */ >>>>...

...8 byte sequence which does > not get decoded every 64 bytes but AFAIK that is the scheduling info, > so that should be fine. > > One thing which does stand out is that this: > > 0: ld u32 %r219 c0[0x0000000000000000+0x0] (0) > 1: ld u32 %r222 c0[0x4] (0) > 2: ld u64 { %r225 %r228 } c0[0x8] (0) > 3: ld u32 %r234 c0[0x10] (0) > > Gets translated into (nvdisasm output) : > > /*0008*/ LDC R4, c[0x0][0x0]; > /* 0x1400000003f11c86 */ > /*0010*/ MOV R2, c[0x0][0x4]; > /* 0x2800400010009de4 */ >...

...tes but AFAIK that is the scheduling info, >>> so that should be fine. >>> >>> One thing which does stand out is that this: >>> >>> 0: ld u32 %r219 c0[0x0000000000000000+0x0] (0) >>> 1: ld u32 %r222 c0[0x4] (0) >>> 2: ld u64 { %r225 %r228 } c0[0x8] (0) >>> 3: ld u32 %r234 c0[0x10] (0) >>> >>> Gets translated into (nvdisasm output) : >>> >>> /*0008*/ LDC R4, c[0x0][0x0]; >>> /* 0x1400000003f11c86 */ >>> /*0010*/...

...gt;> so that should be fine. >>>>> >>>>> One thing which does stand out is that this: >>>>> >>>>> 0: ld u32 %r219 c0[0x0000000000000000+0x0] (0) >>>>> 1: ld u32 %r222 c0[0x4] (0) >>>>> 2: ld u64 { %r225 %r228 } c0[0x8] (0) >>>>> 3: ld u32 %r234 c0[0x10] (0) >>>>> >>>>> Gets translated into (nvdisasm output) : >>>>> >>>>> /*0008*/ LDC R4, c[0x0][0x0]; >>>>> /* 0x1400000003f11c86 *...

...> so that should be fine. >>>>> >>>>> One thing which does stand out is that this: >>>>> >>>>> 0: ld u32 %r219 c0[0x0000000000000000+0x0] (0) >>>>> 1: ld u32 %r222 c0[0x4] (0) >>>>> 2: ld u64 { %r225 %r228 } c0[0x8] (0) >>>>> 3: ld u32 %r234 c0[0x10] (0) >>>>> >>>>> Gets translated into (nvdisasm output) : >>>>> >>>>> /*0008*/ LDC R4, c[0x0][0x0]; >>>>> /* 0x1400000003f11c86...