> -----Original Message-----
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jeff Law
> Sent: Wednesday, May 22, 2013 12:20 PM
> To: Iyer, Balaji V
> Cc: Jakub Jelinek; Richard Henderson; 'Joseph S. Myers'; 'Aldy Hernandez'; 
> 'gcc-
> patches'
> Subject: Re: [PING]RE: [patch] cilkplus: Array notation for C patch
> 
> On 05/22/2013 09:37 AM, Iyer, Balaji V wrote:
> >>>
> >> Furthermore, do you want to generate just normal loop out of it, or
> >> shouldn't we generate a #pragma omp simd loop out of it instead?
> >> Haven't read the spec if array notation guarantees lack of
> >> forward/backward loop dependencies and what are the restrictions on
> >> the calls you can do inside of array notation.  Perhaps the lowering
> >> to normal vs. simd loop could depend on whether all called functions
> >> in the expression are elemental.
> >
> > What you mentioned is a good performance optimization. It is something
> > I have  planned to do in future. But, the spec does not require the
> > loop (or array notation expansion) to be vectorized.
> So if we can represent array notation as an OpenMP SIMD loop and re-use the
> OpenMP code generation, that's a significant win.  I realize the OpenMP SIMD
> stuff is still in-progress, but from a design standpoint we'd like to 
> separate out
> the front-end issues from the code generation issues -- with the goal being 
> that
> we can re-use the OpenMP SIMD path to also handle Cilk SIMD & Cilk array
> notation and possible bits of OpenACC.
> 
> Balaji, how feasible is it to rewire the code generation aspects of the array
> notation patch to instead feed into the OpenMP SIMD bits Jakub is working on?

Hi Jeff,
        Yes, converting the array notation expansion to #pragma simd (or 
#pragma omp simd) trees will be beneficial performance wise. But, it will 
require semi-significant re-write and this can destabilize a currently stable 
implementation. IMHO, for now I would like to keep array notation as is and let 
us see how it interacts with other flavors of gcc backends. At the moment, we 
do not see any reason for instability in this, but we have not done any 
significant testing on non x86 backends. After OMP 4 hits the main-line and 
everything is stable, we could proceed as you indicated.

Thanks,

Balaji V. Iyer.


> 
> 
> Jeff

Reply via email to