> Am 28.02.2024 um 16:05 schrieb Jeff Law <jeffreya...@gmail.com>:
>
>
>
>> 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.
I have some other idea to get away with a leaner not supported query when we’re
before vector lowering. I’ll see how that goes tomorrow.
Richard
> jeff
