This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PING: Re: [patch] implement simd loops in trunk (OMP_SIMD)
- From: Aldy Hernandez <aldyh at redhat dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>, "Iyer, Balaji V" <balaji dot v dot iyer at intel dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, jason merrill <jason at redhat dot com>
- Date: Thu, 08 Aug 2013 14:06:37 +0200
- Subject: Re: PING: Re: [patch] implement simd loops in trunk (OMP_SIMD)
- References: <51DC3405 dot 4070509 at redhat dot com> <51F5F9EB dot 2070205 at redhat dot com> <51FAB937 dot 2040103 at redhat dot com>
+ hash_table <simduid_to_vf> simduid_to_vf_htab;
+ hash_table <decl_to_simduid> decl_to_simduid_htab;
Why two hashes? Seems like you can map from decl to vf directly. At what
point do you have a simduid integer, but not the decl from whence it came?
decl_to_simduid seems to be a misnomer. What it really is, is a
"omp_simd_array_to_simduid" map. OMP simd array, being the temporary
array used to hold simd lane private variable copies and such.
The hash is not really mapping the simd DECL to the simduid, since
that's just a matter of DECL_UID(simduid), but the OMP simd array to the
index used to reference it (simduid), like thus:
_7 = GOMP_SIMD_LANE (simduid.0)
...
...
D.1737[_7] = stuff;
decl_to_simduid is a mapping from the simduid.0 to the D.1737[] (the OMP
simd array).
Agreed, or am I missing something?