On Wed, Dec 02, 2015 at 04:54:39PM +0300, Alexander Monakov wrote:
> On Wed, 2 Dec 2015, Jakub Jelinek wrote:
> > expand_omp is depth-first expansion, so for the case where the simd
> > region is in lexically (directly or indirectly) nested inside of a
> > target region, the above will not trigger. You'd need to
> > use cgraph_node::get (current_function_decl)->offloadable or
> > just walk through outer fields of region up and see if this isn't in
> > a target region.
>
> I've addressed this in my follow-up response to this patch. Again, sorry for
> the mishap, I was overconfident when adjusting the patch just before sending.
>
> > Here, it would be nice to extend omp_max_vf in the host compiler,
> > such that if PTX offloading is enabled, and optimize && !optimize_debug
> > (and vectorizer on the host not disabled, otherwise it won't be cleaned up
> > on the host), it returns MIN (32, whatever it would return otherwise).
>
> Did you mean MAX (32, host_vf), not MIN?
Sure, MAX. Though, if the SIMTification treats "omp simd array" arrays
specially, it probably only cares whether it is > 1 (because 1 disables the
"omp simd array" handling). If all we want to achieve is that those arrays
in PTX ACCEL_COMPILER become again scalars (or aggregates or whatever they
were before) with each thread in warp writing their own, it doesn't really
care about their size that much.
> > How does this even compile? simt_lane is a local var in the if
> > (do_simt_transform) body.
>
> I addressed in this in the reposted patch too, a few hours after posting this
> broken code.
>
> > BTW, again, it would help if you post a simple *.ompexp dump on what exactly
> > you want to look it up.
>
> Sorry, I'm not following you here -- can you rephrase what I should post?
Just wanted to see -fdump-tree-ompexp dump say from the testcase I've
posted. Does your patchset have any dependencies that aren't on the trunk?
If not, I guess I just could apply the patchset and look at the results, but
if there are, it would need applying more.
Jakub
