On Wed, Nov 19, 2014 at 08:52:40PM +0100, Bernd Schmidt wrote:
> Another change that's required is (something like) the following. For ptx,
> we need to know whether to output something as a .func (callable from ptx
> code) or a .kernel (callable from the host). That means we need to mark the
> ker
Hi!
On Thu, 18 Dec 2014 14:16:52 +0100, I wrote:
> --- /dev/null
> +++ gcc/config/i386/intelmic-offload.h
> +#define ACCEL_COMPILER_acc_device GOMP_DEVICE_INTEL_MIC
This one I got right...
> --- /dev/null
> +++ gcc/config/nvptx/offload.h
> @@ -0,0 +1,35 @@
> +#define ACCEL_COMPILER_acc_device
Hi Jakub!
On Thu, 13 Nov 2014 19:09:49 +0100, Jakub Jelinek wrote:
> > --- gcc/builtins.c
> > +++ gcc/builtins.c
> > +static rtx
> > +expand_builtin_acc_on_device (tree exp, rtx target ATTRIBUTE_UNUSED)
> > +{
> > + if (!validate_arglist (exp, INTEGER_TYPE, VOID_TYPE))
> > +return NULL_RTX;
On Thu, Dec 18, 2014 at 12:07:01PM +0100, Thomas Schwinge wrote:
> Many thanks for the review comments! The very most have been addresed,
> here are just a few comments. If you feel strongly/differently about
> any, I'll address those, too.
So, with your latest change both compilers build:
mkdir
Hi Jakub!
On Thu, 18 Dec 2014 13:36:16 +0100, Jakub Jelinek wrote:
> On Thu, Dec 18, 2014 at 01:31:45PM +0100, Jakub Jelinek wrote:
> > > --- gcc/config.gcc
> > > +++ gcc/config.gcc
> > > @@ -2906,6 +2906,7 @@ esac
> > > case ${target} in
> > > *-intelmic-* | *-intelmicemul-*)
> > > tmake_fil
Hi Jakub!
On Thu, 18 Dec 2014 12:33:11 +0100, Jakub Jelinek wrote:
> On Thu, Dec 18, 2014 at 11:46:00AM +0100, Thomas Schwinge wrote:
> > > just
> > > rtx v1 = GEN_INT (...);
> > > rtx v2 = GEN_INT (...);
> > > machine_mode mode = TYPE_MODE (TREE_TYPE (arg));
> > > rtx ret = gen_reg_rtx (
On Thu, Dec 18, 2014 at 01:31:45PM +0100, Jakub Jelinek wrote:
> > --- gcc/config.gcc
> > +++ gcc/config.gcc
> > @@ -2906,6 +2906,7 @@ esac
> > case ${target} in
> > *-intelmic-* | *-intelmicemul-*)
> > tmake_file="${tmake_file} i386/t-intelmic"
> > + tm_file="${tm_file} i386/intelmic-offlo
On Thu, Dec 18, 2014 at 01:24:20PM +0100, Thomas Schwinge wrote:
> Hi Jakub!
>
> On Thu, 18 Dec 2014 13:15:38 +0100, Jakub Jelinek wrote:
> > On Thu, Dec 18, 2014 at 01:02:22PM +0100, Jakub Jelinek wrote:
> > > On Thu, Dec 18, 2014 at 12:38:53PM +0100, Jakub Jelinek wrote:
> > > > So, is what is
Hi Jakub!
On Thu, 18 Dec 2014 13:15:38 +0100, Jakub Jelinek wrote:
> On Thu, Dec 18, 2014 at 01:02:22PM +0100, Jakub Jelinek wrote:
> > On Thu, Dec 18, 2014 at 12:38:53PM +0100, Jakub Jelinek wrote:
> > > So, is what is on the gomp-4_0-branch now all that you'd like to merge to
> > > trunk now?
On Thu, Dec 18, 2014 at 01:02:22PM +0100, Jakub Jelinek wrote:
> On Thu, Dec 18, 2014 at 12:38:53PM +0100, Jakub Jelinek wrote:
> > So, is what is on the gomp-4_0-branch now all that you'd like to merge to
> > trunk now? Has it been tested on nvptx? I guess we should test it with
> > XeonPhi offl
On Thu, Dec 18, 2014 at 12:38:53PM +0100, Jakub Jelinek wrote:
> So, is what is on the gomp-4_0-branch now all that you'd like to merge to
> trunk now? Has it been tested on nvptx? I guess we should test it with
> XeonPhi offloading too to make sure it doesn't break.
> And then you or together wi
On Thu, Dec 18, 2014 at 12:07:01PM +0100, Thomas Schwinge wrote:
> > > - case GF_OMP_FOR_KIND_SIMD:
> > > - kind = " simd";
> > > - break;
> > > - case GF_OMP_FOR_KIND_CILKSIMD:
> > > - kind = " cilksimd";
> > > - break;
> > > case GF_OMP_FOR_KIND_DISTRIBUTE:
> > > kind = " distribute
On Thu, Dec 18, 2014 at 11:46:00AM +0100, Thomas Schwinge wrote:
> > just
> > rtx v1 = GEN_INT (...);
> > rtx v2 = GEN_INT (...);
> > machine_mode mode = TYPE_MODE (TREE_TYPE (arg));
> > rtx ret = gen_reg_rtx (TYPE_MODE (integer_type_node));
> > emit_move_insn (ret, const0_rtx);
> > rtx
Hi Jakub!
Many thanks for the review comments! The very most have been addresed,
here are just a few comments. If you feel strongly/differently about
any, I'll address those, too.
On Thu, 13 Nov 2014 19:09:49 +0100, Jakub Jelinek wrote:
> On Thu, Nov 13, 2014 at 05:59:11PM +0100, Thomas Schwi
Hi!
On Thu, 13 Nov 2014 19:09:49 +0100, Jakub Jelinek wrote:
> On Thu, Nov 13, 2014 at 05:59:11PM +0100, Thomas Schwinge wrote:
> > --- gcc/builtins.c
> > +++ gcc/builtins.c
> > +/* Expand OpenACC acc_on_device.
> > +
> > + This has to happen late (that is, not in early folding;
> > expand_bu
On 11/20/2014 07:52 AM, Jakub Jelinek wrote:
On Thu, Nov 20, 2014 at 03:19:11AM +0100, Bernd Schmidt wrote:
Thomas had apparently already pointed out an issue with the new gomp_target
class (there are multiple similar types of statements we want to handle with
OpenACC, they have different codes
On Thu, Nov 20, 2014 at 03:19:11AM +0100, Bernd Schmidt wrote:
> Thomas had apparently already pointed out an issue with the new gomp_target
> class (there are multiple similar types of statements we want to handle with
> OpenACC, they have different codes but we want to have function pointers
> op
On Wed, Nov 19, 2014 at 08:52:40PM +0100, Bernd Schmidt wrote:
> Another change that's required is (something like) the following. For ptx,
> we need to know whether to output something as a .func (callable from ptx
> code) or a .kernel (callable from the host). That means we need to mark the
> ker
Another change that's required is (something like) the following. For
ptx, we need to know whether to output something as a .func (callable
from ptx code) or a .kernel (callable from the host). That means we need
to mark the kernel functions somehow in omp-low.c, and the following
does that by
On 11/19/2014 02:50 AM, Bernd Schmidt wrote:
@@ -8417,6 +8926,9 @@ expand_omp_target (struct omp_region *region)
/* Add the new function to the offload table. */
vec_safe_push (offload_funcs, child_fn);
+ /* Add the new function to the offload table. */
+ vec_safe_pu
On Thursday 2014-11-13 17:59, Thomas Schwinge wrote:
> Here is our current set of OpenACC middle end changes. As discussed
> before, this is not yet all of OpenACC 2.0 -- we shall a) document what
> is working already, and b) continue to work on closing the gap.
As David wrote in a different cont
On Fri, Nov 14, 2014 at 11:28:15AM +0100, Richard Biener wrote:
> > This patch is based on the last merge of trunk into gomp-4_0-branch,
> > 9be82689 (trunk r216846, 2014-10-29), and still includes an old version
> > of the offloading patches, as currently present on gomp-4_0-branch.
> > We're alre
On 11/13/2014 11:09 AM, Jakub Jelinek wrote:
> On Thu, Nov 13, 2014 at 11:03:47AM -0800, Cesar Philippidis wrote:
@@ -233,6 +242,90 @@ static tree scan_omp_1_op (tree *, int *, void *);
*handled_ops_p = false; \
break;
+/* Helper function to get the reductio
On Thu, 13 Nov 2014, Thomas Schwinge wrote:
> gcc/doc/invoke.texi | 14
You're adding documentation for -fopenacc, but I don't see any .opt file
changes in this patch, and I'd expect the option to be added in the same
patch as its documentation.
--
Joseph S. Myers
On Thu, Nov 13, 2014 at 11:03:47AM -0800, Cesar Philippidis wrote:
> >> @@ -233,6 +242,90 @@ static tree scan_omp_1_op (tree *, int *, void *);
> >>*handled_ops_p = false; \
> >>break;
> >>
> >> +/* Helper function to get the reduction array name */
> >> +static const char *
> >>
I'll try to respond to the reduction stuff. It's been a while since I
started working on it, so I may have lost some state.
On 11/13/2014 10:09 AM, Jakub Jelinek wrote:
>> @@ -233,6 +242,90 @@ static tree scan_omp_1_op (tree *, int *, void *);
>>*handled_ops_p = false; \
>>break;
On Thu, Nov 13, 2014 at 05:59:11PM +0100, Thomas Schwinge wrote:
> * should gcc/oacc-builtins.def just be merged into
> gcc/omp-builtins.def;
Why not. The reason why they aren't in gcc/builtins.def is that
the Fortran FE doesn't source those, but OpenACC supports the same
languages as OpenM
27 matches
Mail list logo
