On 2/28/24 03:05, Richard Biener wrote:
Untested fix for targets that cannot handle the original IL below.
I'm not convinced that's the way to go here, is it? Or scrap
the testcase? Or have a cheap way to say "this target doesn't
support _any_ vec_cond"?
Another way, but for stage1 I think, would be to delay all the
vector checking to the "final" maybe_push_res_to_seq, but that
requires aggressively cleaning out intermediate folding results
no longer needed and also still requires patterns to do the
"is the incoming IL supported on the target" as later we do not
know what parts we matched (this could in theory be automated
as well, of course). There's also no way to say "don't apply
this unless the final simplification result is a constant".
While we might be able to add a new '*' modifier saying
"if the result is supported by the target" there's again no
way of conditionalizing this on the original operation being
supported. OK, maybe on the match allow '*1' and when '*1'
is used in the result we fail if any of the '*1' annotated
parts in the match were supported but at least one of the '*1'
in the result is not. Supported only for select operations.
But it still doesn't help as we'd have to somehow check the
re-simplified result and we can't really track where a
vec_cond we put in goes.
So I don't mind completely deferring to the next stage1; I don't
consider this a significant quality regression and if we think we can do
something cleaner and avoid the pattern explosion I certainly don't mind
waiting.
Seems like we ought to open a bug so it doesn't get lost, particularly
if you'd prefer to defer.
jeff