Re: PING: Fwd: Re: [patch] implement Cilk Plus simd loops on trunk

[Aldy Hernandez <aldyh at redhat dot com>]

On 11/15/13 00:37, Jakub Jelinek wrote:
> On Thu, Nov 14, 2013 at 06:29:50PM -0700, Aldy Hernandez wrote:
> > > Well, if you don't change anything in omp-low.c, then it wouldn't diagnose
> > > setjmp call in #pragma simd, but given that also the OpenMP 4.0 spec
> > > requires that #pragma omp simd doesn't contain calls to setjmp or longjmp
> > > (ditto for #pragma omp declare simd functions), then scan_omp_1_stmt
> > > should be changed to also call check_omp_nesting_restrictions for
> > > setjmp/longjmp calls (the GIMPLE_CALL case then in
> > > check_omp_nesting_restrictions can't assume all calls it sees are
> > > BUILT_IN_NORMAL).
> >
> > Fixed in scan_omp_1_stmt.
>
> Well, setjmp_call_p is not just setjmp, but various other functions,
> including getcontext, fork, vfork and many others, but it isn't longjmp.
> I'd say we should just follow the spec and look solely for setjmp/longjmp,
> for the others perhaps we can warn (though I think it isn't a big deal,
> we are never going to vectorize those), but not error.

Hmm, I thought we could error on all those other context changing 
functions, but you're right... error may be too big of a hammer.  I have 
changed the patch to error on explicit setjmp/longjmp as well as the 
corresponding built-ins.

> > > Perhaps some bool is_cilkplus = false argument to
> > > cp_parser_omp_clause_reduction would work for me (and for C too).
> >
> > Ok, I'm at a loss here, what parts of cp_parser_omp_clause_reduction
> > are the user-defined reductions?  I'm an OpenMP weenie.
>
> I guess it depends on what the Cilk+ spec says about reduction clause,
> and from what I saw it is just too vague.
> http://software.intel.com/sites/products/documentation/doclib/stdxe/2013/composerxe/compiler/cpp-win/index.htm#GUID-44B505B6-01AF-4865-8DF4-AF851F51DDA1.htm
> just mentions
> reduction(oper:var1 [,var2]â)         oper is a reduction operator.
>
> So, the question is which reduction operators does it allow, for what
> types, and what is the exact grammar for oper in that case.
>
> E.g. shall it only allow the +/-/*/&/&&/|/|| that OpenMP 2.5 had?
> Or also min/max that OpenMP 3.1 added?
> Shall it (for C++) allow stuff like reduction(operator +:var1) ?
> And UDRs?  Shall it allow something OpenMP doesn't allow?
>
> Depending to answer to those questions, the changes will differ.
> E.g. if you only allow the OpenMP 2.5 stuff, then you'd fail in
> cp_parser_omp_clause_reduction in
> switch (cp_lexer_peek_token (parser->lexer)->type)'s
> default: break; - default: if (is_cilkplus) goto resync_fail; break;
> with some error message.  If you want also min/max, you'd need
> to add the fail after min/max recognition, but before recognition
> of operator XYZ, if you want to allow even that, but not UDRs,
> you'd fail before id = omp_reduction_id (code, id, NULL_TREE); if
> code is still ERROR_MARK.
>
> 	Jakub

Looks like we need to wait on Intel to pontificate on whether UDRs are 
valid or not.  Who knows...maybe no work at all!  Woo hoo!

How does this look?

Aldy

Attachment: curr
Description: Text document