[PATCH] D126085: [RISCV] Add a subtarget feature to enable unaligned scalar loads and stores
Philip Reames via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed May 25 12:59:20 PDT 2022
reames added a comment.
In D126085#3538293 <https://reviews.llvm.org/D126085#3538293>, @asb wrote:
> I don't think it affects this patch (as splitting scalar vs vector features for alignment makes sense regardless of the frontend option), but I had a quick look at the frontend option for this. Looks like on the GCC side it's `-mno-strict-align`. On Arm/AArch64 it's spelled `-munaligned-access` and `__ARM_FEATURE_UNALIGNED` is set. Unless there's some target generic `#define` that's set that I'm missing, it feels like it would be useful to set a define for the RISC-V case as well (and agree this with the GNU folks).
I agree this is separate. What a target defaults to should not be blocked on what a frontend might chose to override. I'll note that these flags don't appear to influence x86 handling of the corresponding cases, so unless this is handled somewhere generically I missed, this isn't RISCV specific in any way.
> One thing I noticed that does affect this patch (and sorry I didn't spot this earlier!), is we should be setting `Tag_RISCV_unaligned_access` when this feature is set (see here <https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc#list-of-attributes>).
Er, I'm sorry, what? Why?
I agree this spec exists, but what purpose does the attribute bit actually serve? There's no interaction with the dynamic loader here. It's a compiler codegen choice.
If you really want, I'm fine adding the attribute wiring (in a separate patch), but this really looks like a spec that is a) out of sync with reality, and b) serves no obvious purpose.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D126085/new/
https://reviews.llvm.org/D126085
More information about the llvm-commits
mailing list