arichardson added a comment. > Well, the documentation mismatch is worth fixing even if the code isn't. But > I think at best your use-case calls for weakening the assertion to be that > any existing address space isn't *different*, yeah. > > Separately, I'm not sure that's really the right representation for a Harvard > architecture (which is what I assume you're trying to extend Clang to > support); I think you should probably just teach the compiler that function > pointers are different.
We have similar issues with CHERI and for us representing it at the clang AST level doesn't work well. What we really need is address spaces on the LLVM function: For that I've submitted is https://reviews.llvm.org/D47541 (based on https://reviews.llvm.org/D37054). I wonder if that would be a better match for your problem? We put all functions either into LLVM address spac 0 or 200 (depending on the flags passed to clang) so we don't need to add any additional information to the clang AST. Do you have different address spaces for different functions or are they just different from data? Repository: rC Clang https://reviews.llvm.org/D47627 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
