search for: sub_sd

All, I've been trying to simplify the way LLVM models sub-register relationships a bit, and the X86 sub_ss and sub_sd sub-register indices are getting in the way. I want to get rid of them. These sub-registers are special, they are only mentioned here: let CompositeIndices = [(sub_ss), (sub_sd)] in { def XMM0: Register<"xmm0">, DwarfRegNum<[17, 21, 21]>; def XMM1: Register<"xm...

Jakob Stoklund Olesen <jolesen at apple.com> writes: > These sub-registers are special, they are only mentioned here: > > let CompositeIndices = [(sub_ss), (sub_sd)] in { > def XMM0: Register<"xmm0">, DwarfRegNum<[17, 21, 21]>; > def XMM1: Register<"xmm1">, DwarfRegNum<[18, 22, 22]>; > ... I'm confused. Below you note that they are used in patterns, so they are certainly mentioned more than just...

On Jul 26, 2012, at 9:43 AM, dag at cray.com wrote: > Jakob Stoklund Olesen <jolesen at apple.com> writes: > >> As far as I can tell, all sub-register operations involving sub_ss and >> sub_sd can simply be replaced with COPY_TO_REGCLASS: >> >> def : Pat<(v4i32 (X86Movsd VR128:$src1, VR128:$src2)), >> (VMOVSDrr VR128:$src1, (EXTRACT_SUBREG (v4i32 VR128:$src2), >> sub_sd))>; >> >> Bec...

...it chooses the larger spill size for the result. This is > the same for sub-register copies and full register copies. So if I understand this correctly, a pattern like this: def : Pat<(f64 (vector_extract (v2f64 VR128:$src), (iPTR 0))), (f64 (EXTRACT_SUBREG (v2f64 VR128:$src), sub_sd))>; will currently use a 128-bit store if it is spilled? That's really not good. If the 128-bit register is not ever used as a 128-bit register, shouldn't the coalescer pick the 64- or 32-bit register? -Dave

Jakob Stoklund Olesen <jolesen at apple.com> writes: >> If the 128-bit register is not ever used as a 128-bit register, >> shouldn't the coalescer pick the 64- or 32-bit register? > > That optimization is not currently implemented for sub-registers. For > example, if you create a GR64 virtual register and only ever use the > sub_32bit sub-register, it would be

...size for the result. This is >> the same for sub-register copies and full register copies. > > So if I understand this correctly, a pattern like this: > > def : Pat<(f64 (vector_extract (v2f64 VR128:$src), (iPTR 0))), > (f64 (EXTRACT_SUBREG (v2f64 VR128:$src), sub_sd))>; > > will currently use a 128-bit store if it is spilled? It will if we coalesce the COPY away, yes. None of this is dependent on our using sub-registers, though. The coalescer treats sub-register copies and full register copies equally. > If the 128-bit register is not ever used...

Hey guys, Are spills/reloads of AVX registers using aligned stores/loads? I can't seem to find the code that aligns the stack slots to 32-bytes. Could someone point me in the right direction? Thanks, Cameron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110825/b5724dec/attachment.html>

...someone point me in the right direction? The register class has 256-bit spill alignment: def VR256 : RegisterClass<"X86", [v32i8, v16i16, v8i32, v4i64, v8f32, v4f64], 256, (sequence "YMM%u", 0, 15)> { let SubRegClasses = [(FR32 sub_ss), (FR64 sub_sd), (VR128 sub_xmm)]; } /jakob

Does anyone know exactly what ComposerIndices in Target.td is all about? I see just one place where it's used in X86 but it's not clear from the comments in Target.td and it's one usage, exactly what this feature is about. Tia. Reed

...ight direction? > > The register class has 256-bit spill alignment: > > def VR256 : RegisterClass<"X86", [v32i8, v16i16, v8i32, v4i64, v8f32, v4f64], > 256, (sequence "YMM%u", 0, 15)> { > let SubRegClasses = [(FR32 sub_ss), (FR64 sub_sd), (VR128 sub_xmm)]; > } > > /jakob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110901/3403477c/attachment.html>