Re: [RFC][PATCH]Merge VEC_COND_EXPR into MASK_STORE after loop vectorization

[Richard Sandiford <richard.sandiford@arm.com>]

Jeff Law <law@redhat.com> writes:
> On 11/20/18 7:57 AM, Renlin Li wrote:
>> Hi Richard,
>> 
>> On 11/14/2018 02:59 PM, Richard Biener wrote:
>>> On Fri, Nov 9, 2018 at 4:49 PM Renlin Li <renlin.li@foss.arm.com> wrote:
>>>>
>>>> Hi Richard,
>>>>
>>>> On 11/09/2018 11:48 AM, Richard Biener wrote:
>>>>> On Thu, Nov 8, 2018 at 5:55 PM Renlin Li <renlin.li@foss.arm.com> wrote:
>>>>>
>>>>>>
>>>>>> Hi Richard,
>>>>>>
>>>>>>
>>> I don't see the masked load here on x86_64 btw. (I don't see
>>> if-conversion generating a load).
>>> I guess that's again when store-data-races are allowed that it uses a
>>> RMW cycle and vectorization
>>> generating the masked variants for the loop-mask.  Which means for SVE
>>> if-conversion should
>>> prefer the masked-store variant even when store data races are allowed?
>> 
>> Yes, it looks like, for SVE, masked-store variant is preferred even when store data races are allowed.

I agree, and I think that would cope with more cases than fixing it up
later.  E.g. the current fixup code requires the load and store to have
the same vuse, so it won't cope with cases in which another store comes
between the mask_load and mask_store.

An easy heuristic would be to test
targetm.vectorize.empty_mask_is_expensive.  If that's false and masked
stores are available, it's probably better to use them than introduce
the data race.

Thanks,
Richard