On Thu, Jul 3, 2014 at 9:23 AM, Diego Novillo <[email protected]> wrote:
> This change is raising the severity of this diagnostic. Do we really want > to cause build failures in this situation when the code is built with > -Werror? > > I think I would be fine with it, if this diagnostic was only triggered > when the user specified a #pragma, but if the failure is in the vectorizer, > with no hints from the user, then I think a warning is too strong. Even > when using #pragma, I'm not sure I'd like a warning here. > I'd put my vote in for having a warning if a #pragma optimization directive could not be followed. This assumes the warning is instructive enough that the user can easily fix the issue. I added support for loop unrolling pragmas (following Tyler's vectorization work) so the focus for us is loop unrolling. For the target we care about (CUDA/GPU) a missed loop unroll can be a massive performance loss and the user should know about it. Whatever is decided, I'll make the diagnostic severity of loop unrolling pragma diagnostics match that of the vectorization ones. Mark > > return false; >> } >> >> @@ -1276,8 +1292,7 @@ >> emitOptimizationRemarkAnalysis( >> F->getContext(), DEBUG_TYPE, *F, L->getStartLoc(), >> "loop not vectorized due to NoImplicitFloat attribute"); >> - emitOptimizationRemarkMissed(F->getContext(), DEBUG_TYPE, *F, >> - L->getStartLoc(), Hints.emitRemark()); >> + emitMissedWarning(F, L, Hints); >> > > Likewise. > > > Diego. >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
