Hi!
I cleaned up this remnant from an earlier OpenACC execution model
implementation:
On Fri, 29 May 2015 18:23:21 +0200, Bernd Schmidt
wrote:
> When predicating the code for OpenACC, we should avoid the entry block
> in an offloaded region, which contains setup code that should be run in
> e
Hi!
On Mon, 01 Jun 2015 13:57:47 +0200, I wrote:
> On Mon, 1 Jun 2015 12:10:12 +0200, Tom de Vries
> wrote:
> > On 29/05/15 18:23, Bernd Schmidt wrote:
> > > When predicating the code for OpenACC, we should avoid the entry block
> > > in an offloaded region, which contains setup code that should
On 06/01/2015 12:10 PM, Tom de Vries wrote:
On 29/05/15 18:23, Bernd Schmidt wrote:
When predicating the code for OpenACC, we should avoid the entry block
in an offloaded region, which contains setup code that should be run in
every thread. The following patch adds a new marker statement that is
Hi!
On Mon, 1 Jun 2015 12:10:12 +0200, Tom de Vries wrote:
> On 29/05/15 18:23, Bernd Schmidt wrote:
> > When predicating the code for OpenACC, we should avoid the entry block
> > in an offloaded region, which contains setup code that should be run in
> > every thread. The following patch adds a
On 29/05/15 18:23, Bernd Schmidt wrote:
When predicating the code for OpenACC, we should avoid the entry block
in an offloaded region, which contains setup code that should be run in
every thread. The following patch adds a new marker statement that is
used to identify this block. Currently, pred
When predicating the code for OpenACC, we should avoid the entry block
in an offloaded region, which contains setup code that should be run in
every thread. The following patch adds a new marker statement that is
used to identify this block. Currently, predication doesn't happen
anyway due to a
