On Tue, Jul 22, 2025 at 12:02 PM Robin Dapp <rdapp....@gmail.com> wrote: > > > So this is the only part I think is odd - there is a dataref, it just > > has only DR_REF as relevant data. I would have expected we can > > adjust vect_supportable_dr_alignment to deal with the scatter/gather > > case. I'm OK with doing it how you did it here, but seeing > > the > > > > /* For now assume all conditional loads/stores support unaligned > > access without any special code. */ > > if (gcall *stmt = dyn_cast <gcall *> (stmt_info->stmt)) > > if (gimple_call_internal_p (stmt) > > && (gimple_call_internal_fn (stmt) == IFN_MASK_LOAD > > || gimple_call_internal_fn (stmt) == IFN_MASK_STORE)) > > return dr_unaligned_supported; > > > > comment in that function I fear there are more cases that might break > > on targets where at least element alignment is required? > > I'm currently testing if we can simplify still and move the checks into > vect_supportable_dr_alignment. > > Is your concern about the IFN_MASK_LOAD regarding riscv? We only use > IFN_MASK_LEN_LOAD/STORE and shouldn't(?) see the non-len IFNs here, so > wouldn't assume general unaligned support.
Note if-conversion emits IFN_MASK_LOAD/STORE, only the vectorizer later emits the LEN variants. So this is about whether there are (might) be uarchs that have vector aligned loads (aka target alignment is sizeof(vector)) and in addition to that have support for misaligned loads but those with still element alignment. The above even says all masked load/store uarchs suport aribitrary byte-aligned (len-)masked vector loads/stores. Richard. > I'm not too familiar with > aarch64's alignment requirements but it seems to have worked fine so far? :) > -- > Regards > Robin >
