https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #17 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 15 Apr 2024, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635 > > --- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #14) > > I think > > > > if (safelen) > > { > > poly_uint64 val; > > safelen = OMP_CLAUSE_SAFELEN_EXPR (safelen); > > if (!poly_int_tree_p (safelen, &val)) > > safelen_int = 0; > > else > > safelen_int = MIN (constant_lower_bound (val), INT_MAX); > > > > should simply become > > > > safelen_int = constant_upper_bound_with_limit (val, INT_MAX); > > > > ? Usually targets do have a limit on the actual length but I see > > constant_upper_bound_with_limit doesn't query such. But it would > > be a more appropriate way to say there might be an actual target limit here? > > OMP_CLAUSE_SAFELEN_EXPR is always an INTEGER_CST, the FEs verify that and > error > if it is not. So, I must say I don't really understand parts of the > r8-5649-g9d2f08ab97be > changes. I can understand the intent to make max_vf a poly_int, but don't > understand why safelen should be, what would it mean and when it would be set > that way? It would be only to "better" encode "infinity". But I see loop->safelen is 'int' but only [0, MAX_INT] is specified so we'd conveniently have say -1 to encode "infinity". We'd have to special case that value anyway?
