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.
Al
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 tr
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
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 = GO
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)
> ...
+ hash_table simduid_to_vf_htab;
+ hash_table 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
> + 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
