lebedev.ri requested changes to this revision. lebedev.ri added a comment. This revision now requires changes to proceed.
(temporarily undoing my review since it looks like things may change) In D71499#1801302 <https://reviews.llvm.org/D71499#1801302>, @arichardson wrote: > ... Aha! :) In D71499#1801302 <https://reviews.llvm.org/D71499#1801302>, @arichardson wrote: > However, I think this means that for the downstream CHERI codegen > there is one more case where we need to be careful > (but that shouldn't matter for upstream). > For us `uintptr_t` is represented as `i8 addrspace(200)*`. > As `uintptr_t` can hold values that are plain integers and not pointers, > we would need to add the inbounds only if the AST type is a pointer, > and use a non-inbounds GEP for `(u)intptr_t`. I may be missing some details, but won't we get that for free, since we only do `gep` for pointers already? In D71499#1801302 <https://reviews.llvm.org/D71499#1801302>, @arichardson wrote: > Does that sound correct or did I misunderstand something? To //me// this all sounds great. Since we get to dictate^W define semantics, i'd think we can require In D71499#1801302 <https://reviews.llvm.org/D71499#1801302>, @arichardson wrote: > both input and output should be a `Logical pointer`. > If you want random values, you should be aligning uintptr_t instead. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71499/new/ https://reviews.llvm.org/D71499 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
