On Thu, Aug 22, 2024 at 8:03 AM Qing Zhao <qing.z...@oracle.com> wrote: > > On Aug 21, 2024, at 18:08, Bill Wendling <isanb...@gmail.com> wrote: > >> For the unary operator __counted_by(PTR), “PTR” must have a counted_by > >> attribute, if not, there will be a compilation time error. > >> > >> Then the user could write the following code: > >> > >> If __builtin_has_attriubtes (PTR,counted_by) > >> __counted_by(PTR) = COUNT; > >> > >> > >> From the design point of view, I think this might be the cleanest solution. > >> > >> However, currently, CLANG doesn’t have __builtin_has_attributes. In order > >> to provide a consistent interface, __builtin_get_counted_by(PTR) is fine. > >> > > This was the confusion I had during our meeting today. For the above > > to be a compilation time error, we would have to diagnose it after > > DCE, which is okay, but seems like we're opening ourselves up to > > future issues when DCE misses. Maybe not the biggest concern, but... > > Does the DCE above mean "dead code elimination”?
Yes. > If so, I am a little confused: CLANG has dead code elimination pass in the FE? Not that I'm aware of. > Could you explain a little bit here in details to clarify the issues? A small > example will be helpful. Clang's front-end goes through a few phases, of course: parsing, sema, LLVM IR code generation. I'm implementing our version partly in Sema and the rest in LLVM IR generation. During Sema, I check the 'counter's type and adjust the builtin to return a pointer to that type. Future checks determine that the types are compatible. Then IR generation converts the builtins into accesses to the counter. My worry about DCE isn't super high on my list of things to worry about, as it should eliminate a 'if (0) ...' pretty easily, but I don't like relying on future passes to clean up bad code. It's probably me just being too paranoid though, so we don't need to discuss it further. > (In the current GCC’s implementation, I implement this feature completely in > C parser). > -bw
