pcc added inline comments.
================ Comment at: llvm/include/llvm/IR/Intrinsics.td:1640 +def int_asan_check_memaccess : + Intrinsic<[],[llvm_ptr_ty, llvm_i8_ty, llvm_i8_ty], ---------------- kstoimenov wrote: > eugenis wrote: > > vitalybuka wrote: > > > pcc wrote: > > > > eugenis wrote: > > > > > vitalybuka wrote: > > > > > > kstoimenov wrote: > > > > > > > vitalybuka wrote: > > > > > > > > vitalybuka wrote: > > > > > > > > > PTAL at lvm.read_register.i32 > > > > > > > > > > > > > > > > > > How about: > > > > > > > > > > > > > > > > > > llvm.asan.check.memaccess -> > > > > > > > > > lvm.asan.check_read > > > > > > > > > lvm.asan.check_write > > > > > > > > > lvm.asan.kernel.check_read > > > > > > > > > lvm.asan.kernel.check_write > > > > > > > > > > > > > > > > > > Even better > > > > > > > > > lvm.asan.check_read.{i8, i16, i32, ...} > > > > > > > > > lvm.asan.check_write.{i8, i16, i32, ...} > > > > > > > > > lvm.asan.kernel.check_read.{i8, i16, i32, ...} > > > > > > > > > lvm.asan.kernel.check_write.{i8, i16, i32, ...} > > > > > > > > > > > > > > > > > Looks like underscore is not used in intrinsic names, so > > > > > > > > essentially the same with dots. > > > > > > > Sounds good to me. I do the full expansion so there will be 20 > > > > > > > intrinsics altogether. I will update the code and ping you when > > > > > > > done. > > > > > > @pcc @eugenis > > > > > > WDYT, I think later we can do the same for HWASAN? > > > > > I don't see what these multiple intrinsics give us that a single > > > > > memaccess one does not provide? > > > > > > > > > > As long as access type and similar arguments are immediates. > > > > > > > > > Agree with @eugenis - these sorts of intrinsic variants are typically > > > > used for distinguishing different pointer element types and we're in > > > > the process of getting rid of those anyway. > > > @pcc @eugenis Then do you prefer to encode is_write+size+kernel into > > > non-human unreadable AccessInfo, like hwasan, or separate 0/1 arguments. > > > I probably prefer AccessInfo, as they both unreadable, but the hwasan > > > version is shorter. > > don't have a strong opinion, but sometimes I wish that hwasan outlined > > function names were more readable. The magic number in the names takes > > effort to decode. > > > I think I am gonna go with int_asan_check(?_kernel)_(load|store) and pass the > size as parameter. What do you think? You mean in a register? I think that could mean more register pressure -> higher code size. The magic numbers are unfortunate but they aren't that hard to decode (maybe we should be printing them as hex to make it a bit easier). I suppose we could pretty print the access info into the symbol name but only a few people will be looking at these so I'm not sure it's worth the effort. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D107850/new/ https://reviews.llvm.org/D107850 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits