On Thu, Jan 19, 2017 at 04:36:25PM +0300, Alexander Monakov wrote:
> On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> > > Inlining needs to do just like omp-low; if we take the current framework,
> > > it
> > > would need to collect addressable locals into one struct, replace
> > > references to
> > > those locals by field references in the inlined body. Then it needs to
> > > appropriately increase allocation size/alignment in SIMT_ENTER() call
> > > arguments.
> > > And finally it would need to initialize the pointer to structure, either
> > > immediately after SIMT_ENTER, or in a more fine-grained manner by a
> > > __builtin_alloca_with_align-like function (__b_a_w_a is not usable for
> > > that
> > > itself, because currently for known sizes gcc can make it a local
> > > variable).
> >
> > One of the problems with that is that it means that you can't easily turn
> > addressable private variables into non-addressable ones once you force them
> > into such struct that can't be easily SRA split.
> > In contrast, if you can get the variable flags/attributes work, if they
> > become non-addressable (which is especially important to get rid of C++
> > abstraction penalties), you simply don't add them into the specially
> > allocated block.
>
> I agree; I'd like to implement the approach with per-variable attributes once
> it's clear how it ought to work (right now I'm not sure if placing CLOBBERs on
> both entry and exit would be enough; if I understood correctly, Richard is
> saying they might be moved, unless the middle-end is changed to prevent it).
I think we drop CLOBBERs in certain cases, though primarily those with
MEM_REF on the lhs rather than just VAR_DECL, or even with VAR_DECL in EH
optimizations if the clobbers are the sole thing in the EH pad.
I think adding the abnormal edges would look safest to me, after all, before
it is fully lowered it is kind like a loop, some threads in the warp might
bypass it. We also use abnormal edges for vfork etc.
> Do you want me to pursue that during the early days of stage 4? I think it
> would be nice to have the issue addressed in some way for the upcoming
> release.
Yeah, I'd appreciate if this could be resolved during stage 4, especially if
the changes will have as few changes to the non-GOMP_USE_SIMT paths as
possible.
Jakub
