Richard Biener <richard.guent...@gmail.com> writes:
> On Wed, Jun 24, 2020 at 9:13 AM Richard Sandiford
> <richard.sandif...@arm.com> wrote:
>>
>> "Kewen.Lin" <li...@linux.ibm.com> writes:
>> > Hi,
>> >
>> > When I am working on IFNs for vector with length, I noticed that the
>> > current optab support query for mask_load/mask_store looks unexpected.
>> > The mask_load/mask_store requires two modes for convert_optab query,
>> > but the macros direct_mask_{load,store}_optab_supported_p uses
>> > direct_optab_supported_p which asserts type pair should have the same mode.
>> >
>> > I'm not sure whether we have some special reason here or just a typo,
>> > since everything goes well now, mask_{load,store} optab check is mainly
>> > handled by can_vec_mask_load_store_p.
>> >
>> > But if we have some codes as below (eg: one checking for all IFNs finally)
>> >
>> > tree_pair types = direct_internal_fn_types (ifn, call);
>> > if(direct_internal_fn_supported_p (ifn, types, OPTIMIZE_FOR_SPEED) ...
>> >
>> > It will cause ICE.
>> >
>> > Does it make sense to fix it?
>> >
>> > Thanks in advance!
>> >
>> > BR,
>> > Kewen
>> > -----
>> > gcc/ChangeLog:
>> >
>> > * internal-fn.c (direct_mask_load_optab_supported_p): Use
>> > convert_optab_supported_p instead of direct_optab_supported_p.
>> > (direct_mask_store_optab_supported_p): Likewise.
>>
>> OK, thanks.
>>
>> I keep meaning to experiment with dropping the second mode from these optabs,
>> since it should be uniquely determined by the first. That would make things
>> slightly simpler and more consistent with the other load/store IFNs. But as
>> usual I've never found the time.
>
> AVX512 would have V16SImode and SImode because the mask would have
> an integer mode? Likewise I could imagine RISC-V using V4SImode and V4QImode
> or however their mask registers look like.
But what I mean is, once you know the vector mode, there should only
be one “choice” of mask mode. (I agree it might not be the same mode,
and isn't for SVE as well as AVX512.) TARGET_GET_MASK_MODE and related
vectoriser masking code is based around the assumption that the mask
mode is a function of the vector mode.
This is similar to single-mode direct optabs like vec_pack and vec_unpack,
which operate on pairs of vector modes, but where one mode is uniquely
determined by the other.
In contrast, convert optabs are AIUI designed for cases where there are
two modes that can vary independently of one another (at least to some
extent), and so giving a single mode isn't enough to identity the operation.
Thanks,
Richard
