On 08/19/13 13:18, Aldy Hernandez wrote:
Well, apparently this last revision was approved and I didn't even know
about it :).
Tested one last time against current trunk and committed as revision 202029.
My apologies to Jakub for the merge problems he will inherit on the
gomp-4_0-branch.
On Thu, Aug 08, 2013 at 09:15:54PM +0200, Aldy Hernandez wrote:
On 08/08/13 18:42, Richard Henderson wrote:
On 08/08/2013 02:06 AM, Aldy Hernandez wrote:
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
On Thu, Aug 01, 2013 at 09:38:31AM -1000, Richard Henderson wrote:
+ if (simd
+ /*
+ || (fd-sched_kind == OMP_CLAUSE_SCHEDULE_STATIC
+ !fd-have_ordered)*/)
Debugging leftovers or what?
gomp-4_0-branch contains also the || there, but for the trunk merge
I
+ 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.
On 08/08/2013 02:06 AM, Aldy Hernandez wrote:
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)
...
On 08/08/13 18:42, Richard Henderson wrote:
On 08/08/2013 02:06 AM, Aldy Hernandez wrote:
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 =
+ if (simd
+ /*
+ || (fd-sched_kind == OMP_CLAUSE_SCHEDULE_STATIC
+ !fd-have_ordered)*/)
Debugging leftovers or what?
+ /* Enforce simdlen 1 in simd loops with data sharing clauses referencing
+ variable sized vars. That is unnecessarily hard to support
