vitalybuka 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],
----------------
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.
>
AccessInfo
================
Comment at: llvm/include/llvm/IR/Intrinsics.td:1640
+def int_asan_check_memaccess :
+ Intrinsic<[],[llvm_ptr_ty, llvm_i8_ty, llvm_i8_ty],
----------------
pcc wrote:
> kstoimenov wrote:
> > vitalybuka 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.
> > > >
> > > AccessInfo
> > 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.
> I think I am gonna go with int_asan_check(?_kernel)_(load|store) and pass the
> size as parameter. What do you think?
Looks like both @pcc and @eugenis do not like multiple intrinsic.
Also I chatted with @eugenis to clarify the last comment. He is OK with
AccessInfo like in hwasan.
================
Comment at: llvm/include/llvm/IR/Intrinsics.td:1640
+def int_asan_check_memaccess :
+ Intrinsic<[],[llvm_ptr_ty, llvm_i8_ty, llvm_i8_ty],
----------------
vitalybuka wrote:
> pcc wrote:
> > kstoimenov wrote:
> > > vitalybuka 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.
> > > > >
> > > > AccessInfo
> > > 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.
> > I think I am gonna go with int_asan_check(?_kernel)_(load|store) and pass
> > the size as parameter. What do you think?
> Looks like both @pcc and @eugenis do not like multiple intrinsic.
>
> Also I chatted with @eugenis to clarify the last comment. He is OK with
> AccessInfo like in hwasan.
>
>
> I think I am gonna go with int_asan_check(?_kernel)_(load|store) and pass the
> size as parameter. What do you think?
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
