On 17 February 2014 14:47, Tim Prince <n...@aol.com> wrote: > I'm continuing discussions with former Intel colleagues. If you are asking > for insight into how Intel priorities vary over time, I don't expect much, > unless the next beta compiler provides some inferences. They have talked > about implementing all of OpenMP 4.0 except user defined reduction this > year. That would imply more activity in that area than on cilkplus,
I'm expecting this. Any proposal to support Cilk in LLVM would be purely temporary and not endorsed in any way. > although some fixes have come in the latter. On the other hand I had an > issue on omp simd reduction(max: ) closed with the decision "will not be > fixed." We still haven't got pragmas for induction/reduction logic, so I'm not too worried about them. > I have an icc problem report in on fixing omp simd safelen so it is more > like the standard and less like the obsolete pragma simd vectorlength. Our width metadata is slightly different in that it means "try to use that length", rather than "it's safe to use that length", this is why I'm holding on use safelen for the moment. > Also, I have some problem reports active attempting to get clarification of > their omp target implementation. Same here... RTFM is not enough in this case. ;) > You may have noticed that omp parallel for simd in current Intel compilers > can be used for combined thread and simd parallelism, including the case > where the outer loop is parallelizable and vectorizable but the inner one is > not. That's my fear of going with omp simd directly. I don't want to be throwing threads all over the place when all I really want is vector code. For the time, my proposal is to use legacy pragmas: vector/novector, unroll/nounroll and simd vectorlength which map nicely to the metadata we already have and don't incur in OpenMP overhead. Later on, if OpenMP ends up with simple non-threaded pragmas, we should use those and deprecate the legacy ones. If GCC is trying to do the same thing regarding non-threaded-vector code, I'd be glad to be involved in the discussion. Some LLVM folks think this should be an OpenMP discussion, I personally think it's pushing the boundaries a bit too much on an inherently threaded library extension. cheers, --renato
