On Wed, Feb 01, 2017 at 08:09:27PM +0300, Alexander Monakov wrote:
> > That said, I think pointers to gimple stmts in struct loop or something
> > similar is problematic, you'd need to adjust those whenever something would
> > remove those stmts, or e.g. duplicate the loop and stmts, handle those
>
On Wed, 1 Feb 2017, Jakub Jelinek wrote:
> > Yes; I imagine the approach taken in patch 2/5 can be extended to achieve
> > this.
> > That is, instead of just storing a flag 'bool in_simtreg' in struct loop,
> > store
> > pointers to corresponding SIMT_ENTER/EXIT gimple statements, use a similar
>
On Wed, Feb 01, 2017 at 06:44:39PM +0300, Alexander Monakov wrote:
> > That said, I understand how would you add these &varN arguments during
> > lowering, but don't understand what would you want to do during inlining,
> > if you have addressable vars in inlined function, you need to avoid
> > esc
On Wed, 1 Feb 2017, Jakub Jelinek wrote:
> IFN_ASAN_POISON is treated that way too. That also means that if a
> variable is previously addressable and the only spot that takes its address
> is that IFN, it can be rewritten into SSA form, but the IFN has to be
> adjusted to something different whic
On Wed, Feb 01, 2017 at 04:28:14PM +0300, Alexander Monakov wrote:
> Hi,
>
> Earlier Richard mentioned the possibility to special-case GOMP_SIMT_ENTER to
> allow passing privatized variables to it by reference without making them
> addressable. I now see that such special-casing is already done f
Hi,
Earlier Richard mentioned the possibility to special-case GOMP_SIMT_ENTER to
allow passing privatized variables to it by reference without making them
addressable. I now see that such special-casing is already done for
IFN_ATOMIC_COMPARE_EXCHANGE in tree-ssa.c: execute_update_addresses_taken
Hi,
Here's a different approach that doesn't introduce indirection for privatized
variables at all, and keeps dependencies obvious in the IR, but, on the flip
side, requires mentioning all subfields of privatized structures in a few
places.
For each privatized variable, add it to the list of outp
On Thu, 19 Jan 2017, Jakub Jelinek wrote:
> On Thu, Jan 19, 2017 at 04:36:25PM +0300, Alexander Monakov wrote:
> > > 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 str
On 01/18/2017 06:22 AM, Richard Biener wrote:
> On Wed, Jan 18, 2017 at 3:11 PM, Alexander Monakov wrote:
>> On Wed, 18 Jan 2017, Richard Biener wrote:
After OpenMP lowering, inlining might break this by inlining functions with
address-taken locals into SIMD regions. For now, such inlin
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
> > >
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
> > appropr
On Thu, Jan 19, 2017 at 11:00 AM, Jakub Jelinek wrote:
> On Thu, Jan 19, 2017 at 10:45:08AM +0100, Richard Biener wrote:
>> > But in the escape analysis we could consider all the specially marked
>> > "omp simt private" addressable vars to escape and thus confine them into
>> > the
>> > SIMT regi
On Thu, 19 Jan 2017, Jakub Jelinek wrote:
> On Thu, Jan 19, 2017 at 10:45:08AM +0100, Richard Biener wrote:
> > > But in the escape analysis we could consider all the specially marked
> > > "omp simt private" addressable vars to escape and thus confine them into
> > > the
> > > SIMT region that wa
On Thu, Jan 19, 2017 at 10:45:08AM +0100, Richard Biener wrote:
> > But in the escape analysis we could consider all the specially marked
> > "omp simt private" addressable vars to escape and thus confine them into the
> > SIMT region that way, right?
>
> We could. But that doesn't prevent vars f
On Thu, Jan 19, 2017 at 10:44 AM, Alexander Monakov wrote:
> On Thu, 19 Jan 2017, Richard Biener wrote:
>> >> What about motion in the other direction, upwards across SIMT_ENTER()?
>> >
>> > I think this is a question for Richard, whether it can be done in the alias
>> > oracle. If yes, it suppos
On Thu, Jan 19, 2017 at 10:37 AM, Jakub Jelinek wrote:
> On Thu, Jan 19, 2017 at 10:31:38AM +0100, Richard Biener wrote:
>> On Wed, Jan 18, 2017 at 5:22 PM, Jakub Jelinek wrote:
>> > On Wed, Jan 18, 2017 at 07:15:34PM +0300, Alexander Monakov wrote:
>> >> On Wed, 18 Jan 2017, Jakub Jelinek wrote:
On Thu, 19 Jan 2017, Richard Biener wrote:
> >> What about motion in the other direction, upwards across SIMT_ENTER()?
> >
> > I think this is a question for Richard, whether it can be done in the alias
> > oracle. If yes, it supposedly can be done for both SIMT_ENTER and
> > SIMT_EXIT.
>
> Code
On Thu, Jan 19, 2017 at 10:31:38AM +0100, Richard Biener wrote:
> On Wed, Jan 18, 2017 at 5:22 PM, Jakub Jelinek wrote:
> > On Wed, Jan 18, 2017 at 07:15:34PM +0300, Alexander Monakov wrote:
> >> On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> >> > We are talking here about addressable vars, right (so
On Wed, Jan 18, 2017 at 5:22 PM, Jakub Jelinek wrote:
> On Wed, Jan 18, 2017 at 07:15:34PM +0300, Alexander Monakov wrote:
>> On Wed, 18 Jan 2017, Jakub Jelinek wrote:
>> > We are talking here about addressable vars, right (so if we turn it into
>> > non-addressable, in the SIMT region we just use
On Wed, Jan 18, 2017 at 08:02:14PM +0300, Alexander Monakov wrote:
> On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> > > It is, but I think my approach is compatible with inlining too (and has a
> > > more
> > > localized impact on the compiler).
> >
> > But your 2/5 patch disables inlining into the
On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> > It is, but I think my approach is compatible with inlining too (and has a
> > more
> > localized impact on the compiler).
>
> But your 2/5 patch disables inlining into the SIMT regions. Or do you mean
> the approach with some new IFN for the pointers
On Wed, Jan 18, 2017 at 07:15:34PM +0300, Alexander Monakov wrote:
> On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> > We are talking here about addressable vars, right (so if we turn it into
> > non-addressable, in the SIMT region we just use the normal PTX pseudos),
> > right? We could emit inner ={
On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> We are talking here about addressable vars, right (so if we turn it into
> non-addressable, in the SIMT region we just use the normal PTX pseudos),
> right? We could emit inner ={v} {CLOBBER}; before SIMT_EXIT() to make it
> clear it shouldn't be moved a
On Wed, Jan 18, 2017 at 06:34:05PM +0300, Alexander Monakov wrote:
> My main concern is that nothing indicates to optimization passes that after
> SIMT_EXIT(), underlying storage is unavailable. What would prevent the
> compiler
> from transforming, say
>
> SIMT_ENTER();
> // originally omp
On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> On Wed, Jan 18, 2017 at 05:52:49PM +0300, Alexander Monakov wrote:
> > On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> > > Can't it be e.g. recorded inside a flag on the VAR_DECLs or magic
> > > attributes
> > > on them during omplower time and then only fi
On Wed, Jan 18, 2017 at 05:52:49PM +0300, Alexander Monakov wrote:
> On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> > Can't it be e.g. recorded inside a flag on the VAR_DECLs or magic attributes
> > on them during omplower time and then only finalized into the magic .local
> > alloca in the pass_omp_d
On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> Can't it be e.g. recorded inside a flag on the VAR_DECLs or magic attributes
> on them during omplower time and then only finalized into the magic .local
> alloca in the pass_omp_device_lower pass?
No (see my adjacent response): it can't be a variable fl
On Wed, Jan 18, 2017 at 03:32:56PM +0100, Jakub Jelinek wrote:
> > It probably is.
> >
> > But I guess I was asking whether you could initially emit
> >
> > void *omp_simt = IFN_GOMP_SIMT_ENTER (0);
> >
> > for (int i = n1; i < n2; i++)
> > foo (&tmp);
> >
> > IFN_GOMP_SIMT_EXIT (omp_
On Wed, 18 Jan 2017, Richard Biener wrote:
> But I guess I was asking whether you could initially emit
>
> void *omp_simt = IFN_GOMP_SIMT_ENTER (0);
>
> for (int i = n1; i < n2; i++)
> foo (&tmp);
>
> IFN_GOMP_SIMT_EXIT (omp_simt);
>
> and only after inlining do liveness / use analysi
On Wed, Jan 18, 2017 at 03:22:15PM +0100, Richard Biener wrote:
> > So I guess a way to keep allocation layout implicit until after inlining is
> > this: instead of exposing the helper struct in the IR immediately, somehow
> > keep
> > it on the side, associated only with the SIMT region, and not
On Wed, Jan 18, 2017 at 3:11 PM, Alexander Monakov wrote:
> On Wed, 18 Jan 2017, Richard Biener wrote:
>> > After OpenMP lowering, inlining might break this by inlining functions with
>> > address-taken locals into SIMD regions. For now, such inlining is
>> > disallowed
>> > (this penalizes only
On Wed, 18 Jan 2017, Richard Biener wrote:
> > After OpenMP lowering, inlining might break this by inlining functions with
> > address-taken locals into SIMD regions. For now, such inlining is
> > disallowed
> > (this penalizes only SIMT code), but eventually that can be handled by
> > collecting
On Tue, Jan 17, 2017 at 9:07 PM, Alexander Monakov wrote:
> Hello,
>
> This patch series addresses a correctness issue in how OpenMP SIMD regions are
> transformed for SIMT execution. On NVPTX, OpenMP target code runs with
> per-warp stacks outside of SIMD regions, and needs to transition to per-
Hello,
This patch series addresses a correctness issue in how OpenMP SIMD regions are
transformed for SIMT execution. On NVPTX, OpenMP target code runs with
per-warp stacks outside of SIMD regions, and needs to transition to per-lane
stacks on SIMD region boundaries. Originally the plan was to i
34 matches
Mail list logo
