bwendling wrote:
> > ```c
> > struct x {
> > int a;
> > char foo[2][40];
> > int b;
> > int c;
> > };
> >
> > size_t f(struct x *p, int idx) {
> > return __builtin_dynamic_object_size(>foo[idx], 1);
> > }
> > ```
>
> If I'm following correctly, the return here is 0, 40, or
bwendling wrote:
> > maybe we could add the subtype as part of the llvm.objectsize intrinsic and
> > use that instead of grappling with the whole object's type
>
> I'm not sure I follow; if you know the object's type, doesn't that mean you
> also know its size?
Not necessarily. If you have
bwendling wrote:
It matches my understanding too. There are more issues with `__bdos` that arose
due to this discussion and related discussions with the GCC maintainers.
I'm exploring some ways of fixing this issue:
* As @efriedma-quic mentioned, generating the size calculation in the front
nikic wrote:
Thanks for summarizing, that matches my understanding.
As to how to implement this "properly", that would probably be
https://discourse.llvm.org/t/exploring-the-effects-and-uses-of-the-memory-region-declaration-intrinsic/72756.
The memory.region.decl intrinsics effectively encode
efriedma-quic wrote:
Trying to summarize my understanding here:
- Using the type of an alloca in LLVM IR is wrong, for a variety of reasons.
(At this point, the type of an alloca is basically just leftover junk from
before the opaque pointer transition; I expect that we'll kill it off
siddhesh wrote:
> Perhaps we need clarification on what GCC means by "may point to multiple
> objects" in this instance. To me that means either "get me the size of the
> largest of these multiple objects" or "size of the smallest." In my eyes,
> that means pointing to a union field.
>
It's
bwendling wrote:
> > My answer for the question "what's the semantics of GCC's builtin X?" has
> > always been "whatever GCC does." It's the best we can rely upon. But then
> > we get into situations like this, where you and @nikic have one
> > interpretation of their documentation and I have
bwendling wrote:
> > Perhaps we need clarification on what GCC means by "may point to multiple
> > objects" in this instance. To me that means either "get me the size of the
> > largest of these multiple objects" or "size of the smallest." In my eyes,
> > that means pointing to a union field.
zygoloid wrote:
> Perhaps we need clarification on what GCC means by "may point to multiple
> objects" in this instance. To me that means either "get me the size of the
> largest of these multiple objects" or "size of the smallest." In my eyes,
> that means pointing to a union field.
Per
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
bwendling wrote:
> > > But mode 0 and 1 are in general asking for an upper bound on the
> > > accessible bytes (that is, an N so any.access beyond N bytes is
> > > definitely out of bounds), so it seems to me that returning -1 is
> > > strictly worse than returning 48.
> >
> >
> > It's the
zygoloid 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
bwendling wrote:
> > For unions, clang will use the type of the union member with the largest
> > size as the alloca type, regardless of which union member is active. I
> > haven't tried, but your patch will probably compute the subobject size
> > based on that arbitrarily picked member,
zygoloid wrote:
> For unions, clang will use the type of the union member with the largest size
> as the alloca type, regardless of which union member is active. I haven't
> tried, but your patch will probably compute the subobject size based on that
> arbitrarily picked member, rather than
bwendling wrote:
> Perhaps according to the GCC documentation as written. But mode 0 and 1 are
> in general asking for an upper bound on the accessible bytes (that is, an N
> so any.access beyond N bytes is definitely out of bounds), so it seems to me
> that returning -1 is strictly worse
bwendling wrote:
> Using anything but the size and alignment of the alloca type in a way that
> affects program semantics is illegal.
I'm sorry, but I don't understand your comment here. Could you supply some
context?
https://github.com/llvm/llvm-project/pull/78526
bwendling wrote:
> We've discussed this before, years ago. Previously, the sticking point was:
> how is LLVM going to know what the frontend considers the closest surrounding
> subobject to be? The LLVM type doesn't give you that information, and it
> seems like there's nowhere else that LLVM
https://github.com/zygoloid commented:
We've discussed this before, years ago. Previously, the sticking point was: how
is LLVM going to know what the frontend considers the closest surrounding
subobject to be? The LLVM type doesn't give you that information, and it seems
like there's nowhere
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 8947469ec1ad6d35b2feec0acc43d0d191514f0b
ab13650e232b1a17cf9c7335f90a33f7eb71f741 --
llvmbot wrote:
@llvm/pr-subscribers-llvm-globalisel
@llvm/pr-subscribers-backend-amdgpu
@llvm/pr-subscribers-clang-codegen
Author: Bill Wendling (bwendling)
Changes
The second argument of __builtin_dynamic_object_size controls whether it
returns the size of the whole object or the closest
20 matches
Mail list logo
