arichardson wrote: > > > I'm a little concerned with basing the datalayout on features. The > > > datalayout is at the module level, but features are at the function > > > level. We don't really have module level features. The feature string in > > > the TargetMachine is often empty in an LTO build. > > > > > > The main reason I checked the features is to not change the data layout for > > non-RVY compilations, but adding it unconditionally should also be safe. > > You still need the +y attribute for the final assembly generation, so it > > would just an unused component for non-Y compilation. > > Adding it unconditionally would certainly be simpler and less fragile, so I > > would be happy to use that approach instead if you don't mind the extra > > "useless" component for non-Y compilations. > > It's not safe, because it affects optimisations due to needing to consider > the fact that there might be pointers with external state when lowering > memcpy, for example.
While that's currently the behaviour in downstream CHERI LLVM, I think it would be cleanest to have the external state memcpy behaviour not be based on whether the datalayout happens to include pointers with external state or not. I'm not sure if that is feasible in every possible case, but most of the time the frontend should be able to add the correct [annotations/attributes](https://discourse.llvm.org/t/rfc-supporting-pointers-with-external-storage-in-llvm-memcpy-and-friends/89353) and the calls introduced elsewhere should hopefully know whether pointers with external state are being copied. > Given we do not intend to upstream hybrid support due to it being invasive > and hard to use, let's just keep the DataLayout based on the ABI? That would one option, although I was planning to include (at least basic) backend support since that allows testing more of the hwmode logic and could be useful for frontends in the future. https://github.com/llvm/llvm-project/pull/177249 _______________________________________________ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
