ChuanqiXu abandoned this revision. ChuanqiXu added a comment. In D124504#3476585 <https://reviews.llvm.org/D124504#3476585>, @nikic wrote:
> In D124504#3476562 <https://reviews.llvm.org/D124504#3476562>, @ChuanqiXu > wrote: > >> In D124504#3476537 <https://reviews.llvm.org/D124504#3476537>, @nikic wrote: >> >>> How does it block your work? Tests currently still use >>> `-no-opaque-pointers` to avoid breaking this mode. I think it's generally >>> okay to drop the option, but I'm a bit unclear about the motivation in this >>> case -- do you want to make a change that would be incompatible with typed >>> pointers? >> >> The motivation is that I want to insert an intrinsic for TLS variable. The >> whole background could be found at: >> https://discourse.llvm.org/t/address-thread-identification-problems-with-coroutine/62015 >> >> The signature of the intrinsic is `ptr @intrinsic.name(ptr)`. And I must add >> one bitcast if I can't use opaque-pointer. It looks like opaque pointer is >> enabled by default now: >> https://github.com/llvm/llvm-project/blob/86c770346c26ce4c9abf5a5b7ab4b5bbfdcf9d78/clang/include/clang/Driver/Options.td#L5567-L5573 >> >> So I feel like it is better to remove the `--no-opaque-pointers` option. I >> could add a bitcast to workaround if this is not wanted. Maybe the word >> `block` is not suitable here. > > In that case, I'd recommend inserting the bitcast for now, if it's not too > much complication. Also, you might want to consider using an overloaded > intrinsic, in which case a bitcast is not necessary (using an overloaded > intrinsic would also allow pointers of different address spaces, not sure if > that's relevant here). Thanks, I would give it a try. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D124504/new/ https://reviews.llvm.org/D124504 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
