bwendling wrote: > Taking a step back, while this patch is not the right direction, we can and > should do better for the original example. Probably the best way to do that > is to analyze the operand to `__builtin_[dynamic_]object_size` in the > frontend and compute a better bound based on the form of the expression. It > looks like it should be feasible to produce a tighter bound for an > array-to-pointer-decay expression like `f.bar[argc]` in subobject mode, as: > > * `select llvm.is.constant(argc) and (argc < 0 or argc >= 2), 0, > sizeof(f.bar[argc])` for the non-dynamic case, and just > * `select (argc < 0 or argc >= 2), 0, sizeof(f.bar[argc])` for the dynamic > case. > > A possibly simpler alternative would be for the frontend to pass an upper > bound on the result to the LLVM builtin in mode 1, so Clang could say "I know > the result will never be more than 40" and LLVM could provide either that > size or the complete object size, whichever is smaller. That wouldn't give as > tight a bound for the argc == 2 case, though.
It might be possible to do something like this. If retaining precise type information from the front-end is the sticking issue, it could be as simple as casting this pointer top the type of the sub-object. I'll see what I can do. https://github.com/llvm/llvm-project/pull/78526 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
