On Tue, Jun 18, 2013 at 02:15:55PM -0500, Aldy Hernandez wrote:
> >Please move simduid after force_vect, so that it is better packed.
>
> Fixed.
>
> I also rewrote the builtins to use the internal function doo-dah as
> previously suggested.
>
> Let me know if this is fine with y'all and you (Jak
Please move simduid after force_vect, so that it is better packed.
Fixed.
I also rewrote the builtins to use the internal function doo-dah as
previously suggested.
Let me know if this is fine with y'all and you (Jakub) can keep this
patch and apply it on top of your pending patchset for c
On Mon, Jun 17, 2013 at 07:59:15PM -0500, Aldy Hernandez wrote:
> As discussed on IRC. Attached are these changes you requested, plus
> changing OMP_CLAUSE__SIMDUID__UID to OMP_CLAUSE__SIMDUID__DECL.
>
> I will tackle the dot named builtins in the next iteration.
Thanks.
> --- a/gcc/builtin-typ
On 06/17/13 12:23, Richard Henderson wrote:
On 06/17/2013 10:13 AM, Aldy Hernandez wrote:
- data.simduid = tree_low_cst (gimple_call_arg (stmt, 0), 1);
+ data.simduid = gimple_call_arg (stmt, 0);
Doesn't this copy the ADDR_EXPR from the call into simduid?
simduid_to_vf::has
On 06/17/2013 10:13 AM, Aldy Hernandez wrote:
> - data.simduid = tree_low_cst (gimple_call_arg (stmt, 0), 1);
> + data.simduid = gimple_call_arg (stmt, 0);
Doesn't this copy the ADDR_EXPR from the call into simduid?
> simduid_to_vf::hash (const value_type *p)
> {
> - return p->simd
On 06/12/13 16:36, Jakub Jelinek wrote:
On Wed, Jun 12, 2013 at 10:38:00AM -0700, Richard Henderson wrote:
On 06/12/2013 10:30 AM, Jakub Jelinek wrote:
So the built-ins would take address of this decl, something else?
Perhaps address, perhaps just referenced uninitialized?
True, assuming no
On 06/12/13 16:36, Jakub Jelinek wrote:
On Wed, Jun 12, 2013 at 10:38:00AM -0700, Richard Henderson wrote:
On 06/12/2013 10:30 AM, Jakub Jelinek wrote:
So the built-ins would take address of this decl, something else?
Perhaps address, perhaps just referenced uninitialized?
True, assuming no
On Thu, Jun 13, 2013 at 03:15:45PM -0500, Aldy Hernandez wrote:
>
> >it. Also, not sure what to do for lastprivate, probably use the magic
> >arrays and just in the epilogue of the loop compute which of the array items
> >belonged to the last iteration somehow.
>
> Can't you do (for lastprivate(
it. Also, not sure what to do for lastprivate, probably use the magic
arrays and just in the epilogue of the loop compute which of the array items
belonged to the last iteration somehow.
Can't you do (for lastprivate(abc) something like:
if (i == 1024) {
abc = magic_a
On Wed, Jun 12, 2013 at 10:38:00AM -0700, Richard Henderson wrote:
> On 06/12/2013 10:30 AM, Jakub Jelinek wrote:
> > So the built-ins would take address of this decl, something else?
>
> Perhaps address, perhaps just referenced uninitialized?
True, assuming no pass would actually want to change
On 06/12/2013 10:30 AM, Jakub Jelinek wrote:
> So the built-ins would take address of this decl, something else?
Perhaps address, perhaps just referenced uninitialized?
> Then there is the _simduid_ clause (also can hold address of the decl), and
> after lowering it lives only in loop structure (
On Wed, Jun 12, 2013 at 10:21:53AM -0700, Richard Henderson wrote:
> On 04/27/2013 11:17 AM, Jakub Jelinek wrote:
> > where simd_uid would be some say integer constant, unique to the simd loop
> > (at least unique within the same function, and perhaps inlining/LTO would
> > need to remap).
>
> If
On 04/27/2013 11:17 AM, Jakub Jelinek wrote:
> where simd_uid would be some say integer constant, unique to the simd loop
> (at least unique within the same function, and perhaps inlining/LTO would
> need to remap).
If all we need is uniqueness, then perhaps an otherwise unused decl would do?
We'r
On Sat, Apr 27, 2013 at 08:17:35PM +0200, Jakub Jelinek wrote:
> One way we could implement the SIMD private/lastprivate/reduction
> vars and for Cilk+ also firstprivate ones might be:
> - query the target what the maximum possible vectorization factor for the
> loop is (and min that with simdlen
On 05/01/2013 01:53 PM, Aldy Hernandez wrote:
I am not sure about the upcoming spec, but as per today's spec
vectorlength in pragma simd can have multiple parameters and so I
think it would be a good idea to use a max.
As discussed here:
http://software.intel.com/en-us/forums/topic/391056
"
I am not sure about the upcoming spec, but as per today's spec
vectorlength in pragma simd can have multiple parameters and so I
think it would be a good idea to use a max.
As discussed here:
http://software.intel.com/en-us/forums/topic/391056
"The use of multiple vectorlength arguments is b
ect: Re: [gomp4] Some progress on #pragma omp simd
>
> On 05/01/13 10:58, Iyer, Balaji V wrote:
> >>
> >> Well, it looks like things are bit simpler than expected.
> >>
> >> Multiple vectorlength clauses are being deprecated or eliminated in
> >> the upc
On 05/01/13 10:58, Iyer, Balaji V wrote:
Well, it looks like things are bit simpler than expected.
Multiple vectorlength clauses are being deprecated or eliminated
in the upcoming spec. So it looks like vectorlength is the same
thing as the safelen clause.
If you agree then I can get rid of O
ect: Re: [gomp4] Some progress on #pragma omp simd
>
> On 04/24/13 01:01, Jakub Jelinek wrote:
> > On Tue, Apr 23, 2013 at 09:32:29PM +, Iyer, Balaji V wrote:
> >>My apologies if the documentation did not explain this correctly. It
> >> was written by compiler develo
On 04/24/13 01:01, Jakub Jelinek wrote:
On Tue, Apr 23, 2013 at 09:32:29PM +, Iyer, Balaji V wrote:
My apologies if the documentation did not explain this correctly. It
was written by compiler developers and not language developers. #pragma
simd is the guarantee the user gives the c
On 04/28/13 09:45, Iyer, Balaji V wrote:
One more question Balaji, the Cilk Plus spec says that for #pragma simd, the
private, firstprivate, lastprivate, and reduction clauses are as OpenMP.
However, for <#omp simd>, there is no firstprivate in the OpenMP 4.0rc2 spec.
Is the firstprivate clause
ect: Re: [gomp4] Some progress on #pragma omp simd
>
> Hi Balaji.
>
> >> "The syntax and semantics of the various simd-openmp-data-clauses are
> >> detailed in the OpenMP specification.
> >> (http://www.openmp.org/mp-documents/spec30.pdf, Section 2.9.3)."
On Sat, Apr 27, 2013 at 12:30:28PM -0500, Aldy Hernandez wrote:
> >>"The syntax and semantics of the various simd-openmp-data-clauses
> >>are detailed in the OpenMP specification.
> >>(http://www.openmp.org/mp-documents/spec30.pdf, Section 2.9.3)."
> >>
> >>Balaji, can you verify which is correct?
Hi Balaji.
"The syntax and semantics of the various simd-openmp-data-clauses
are detailed in the OpenMP specification.
(http://www.openmp.org/mp-documents/spec30.pdf, Section 2.9.3)."
Balaji, can you verify which is correct? For that matter, which
are the official specs from which we should be
hes@gcc.gnu.org
> Subject: Re: [gomp4] Some progress on #pragma omp simd
>
> [Balaji, see below].
>
> Ok, this is confusing. While the document in the link you posted (the ICC
> manual?) says so, the document I'm following says otherwise.
>
> I'm following this (which
On 04/24/13 01:01, Jakub Jelinek wrote:
The documentation doesn't suggest that. Anyway, so
#pragma simd
should be equivalent to
#pragma omp simd
wrt. inter-iteration dependencies, and
#pragma simd vectorlength(a, b, c)
to
#pragma omp simd safelen(max (a, b, c))
? If so, then the FE could emit
On 04/24/13 18:22, Aldy Hernandez wrote:
Hmmm, furthermore, even if the simd + private semantics in Cilk Plus
have the same semantics of the OpenMP standard, is it the OpenMP 3.0
semantics like the openmp link suggests (private to task), or is it the
OpenMP 4.0 rc 2 semantics which you suggest
[Balaji, see below].
Ok, this is confusing. While the document in the link you posted (the
ICC manual?) says so, the document I'm following says otherwise.
I'm following this (which, until a few days was a link accessible from
the cilk plus web page, though I no longer see it):
http://soft
On Wed, Apr 24, 2013 at 08:25:36AM +0200, Jakub Jelinek wrote:
> BTW, the semantics of private/firstprivate/lastprivate desribed in
> http://software.intel.com/sites/products/documentation/studio/composer/en-us/2011Update/compiler_c/cref_cls/common/cppref_pragma_simd.htm
> doesn't seem to match the
On Wed, Apr 24, 2013 at 08:01:17AM +0200, Jakub Jelinek wrote:
> On Tue, Apr 23, 2013 at 09:32:29PM +, Iyer, Balaji V wrote:
> The documentation doesn't suggest that. Anyway, so
> #pragma simd
> should be equivalent to
> #pragma omp simd
> wrt. inter-iteration dependencies, and
> #pragma simd
On Tue, Apr 23, 2013 at 09:32:29PM +, Iyer, Balaji V wrote:
> My apologies if the documentation did not explain this correctly. It
> was written by compiler developers and not language developers. #pragma
> simd is the guarantee the user gives the compiler that the inter-iteration
> depe
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Tuesday, April 23, 2013 9:55 AM
> To: Aldy Hernandez
> Cc: Richard Henderson; gcc-patches@gcc.gnu.org; Iyer, Balaji V
> Subject: Re: [gomp4] Some progress on #pragma omp simd
>
> On Mo
[Balaji, see below]
On 04/23/13 08:54, Jakub Jelinek wrote:
On Mon, Apr 22, 2013 at 05:05:03PM -0500, Aldy Hernandez wrote:
On 04/19/13 08:29, Jakub Jelinek wrote:
If I understood right, vectorlength isn't anything close to it, it is just a
hint, if you vectorize, prefer this vector length,
On Mon, Apr 22, 2013 at 05:05:03PM -0500, Aldy Hernandez wrote:
> On 04/19/13 08:29, Jakub Jelinek wrote:
> >I've committed the following patch to gomp4 branch.
> >#pragma omp simd loops now are handled with all its clauses from parsing up
> >to and including omp expansion, so should actually run c
On 04/19/13 08:29, Jakub Jelinek wrote:
Hi!
I've committed the following patch to gomp4 branch.
#pragma omp simd loops now are handled with all its clauses from parsing up
to and including omp expansion, so should actually run correctly, though
haven't added any runtime testcases yet.
I like i
Hi!
I've committed the following patch to gomp4 branch.
#pragma omp simd loops now are handled with all its clauses from parsing up
to and including omp expansion, so should actually run correctly, though
haven't added any runtime testcases yet.
#pragma omp for simd is handled only partially, the
36 matches
Mail list logo
