> On Apr 11, 2025, at 14:24, Martin Uecker wrote:
>
> Am Freitag, dem 11.04.2025 um 18:14 + schrieb Qing Zhao:
>>
>>> On Apr 11, 2025, at 13:37, Martin Uecker wrote:
>>>
>>> Am Freitag, dem 11.04.2025 um 17:08 + schrieb Qing Zhao:
> On Apr 11, 2025, at 12:20, Martin Uecker
> On Apr 11, 2025, at 14:12, Martin Uecker wrote:
>
> Am Freitag, dem 11.04.2025 um 13:55 -0400 schrieb Siddhesh Poyarekar:
>> On 2025-04-11 13:37, Martin Uecker wrote:
My understanding is that such issue with the implicit data flow dependency
information missing is only for the
>>>
> On Apr 11, 2025, at 13:55, Siddhesh Poyarekar wrote:
>
> On 2025-04-11 13:37, Martin Uecker wrote:
>>> My understanding is that such issue with the implicit data flow dependency
>>> information missing is only for the
>>> counted_by attribute, not for the other TYPE which already have the bo
Am Freitag, dem 11.04.2025 um 18:14 + schrieb Qing Zhao:
>
> > On Apr 11, 2025, at 13:37, Martin Uecker wrote:
> >
> > Am Freitag, dem 11.04.2025 um 17:08 + schrieb Qing Zhao:
> > >
> > > > On Apr 11, 2025, at 12:20, Martin Uecker wrote:
> > > >
> > > > Am Freitag, dem 11.04.2025 um 1
> On Apr 11, 2025, at 13:37, Martin Uecker wrote:
>
> Am Freitag, dem 11.04.2025 um 17:08 + schrieb Qing Zhao:
>>
>>> On Apr 11, 2025, at 12:20, Martin Uecker wrote:
>>>
>>> Am Freitag, dem 11.04.2025 um 16:01 + schrieb Qing Zhao:
> On Apr 11, 2025, at 10:53, Martin Uecker
Am Freitag, dem 11.04.2025 um 13:55 -0400 schrieb Siddhesh Poyarekar:
> On 2025-04-11 13:37, Martin Uecker wrote:
> > > My understanding is that such issue with the implicit data flow
> > > dependency information missing is only for the
> > > counted_by attribute, not for the other TYPE which alre
On 2025-04-11 13:37, Martin Uecker wrote:
My understanding is that such issue with the implicit data flow dependency
information missing is only for the
counted_by attribute, not for the other TYPE which already have the bound
information there.
The dependency issue is only for the size, but
Am Freitag, dem 11.04.2025 um 17:08 + schrieb Qing Zhao:
>
> > On Apr 11, 2025, at 12:20, Martin Uecker wrote:
> >
> > Am Freitag, dem 11.04.2025 um 16:01 + schrieb Qing Zhao:
> > >
> > > > On Apr 11, 2025, at 10:53, Martin Uecker wrote:
> > > >
> > > > Am Freitag, dem 11.04.2025 um 1
> On Apr 11, 2025, at 12:20, Martin Uecker wrote:
>
> Am Freitag, dem 11.04.2025 um 16:01 + schrieb Qing Zhao:
>>
>>> On Apr 11, 2025, at 10:53, Martin Uecker wrote:
>>>
>>> Am Freitag, dem 11.04.2025 um 10:42 -0400 schrieb Andrew MacLeod:
On 4/11/25 10:27, Qing Zhao wrote:
>
>
On 4/11/25 10:27, Qing Zhao wrote:
On Apr 10, 2025, at 11:12, Martin Uecker wrote:
Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar:
On 2025-04-10 10:50, Andrew MacLeod wrote:
Its not clear to me exactly what is being asked, but I think the
suggestion is that pointe
Am Freitag, dem 11.04.2025 um 16:01 + schrieb Qing Zhao:
>
> > On Apr 11, 2025, at 10:53, Martin Uecker wrote:
> >
> > Am Freitag, dem 11.04.2025 um 10:42 -0400 schrieb Andrew MacLeod:
> > > On 4/11/25 10:27, Qing Zhao wrote:
> > > >
> > > > > On Apr 10, 2025, at 11:12, Martin Uecker wrote
> On Apr 11, 2025, at 10:53, Martin Uecker wrote:
>
> Am Freitag, dem 11.04.2025 um 10:42 -0400 schrieb Andrew MacLeod:
>> On 4/11/25 10:27, Qing Zhao wrote:
>>>
On Apr 10, 2025, at 11:12, Martin Uecker wrote:
Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyar
On 4/11/25 11:36, Qing Zhao wrote:
On Apr 11, 2025, at 10:42, Andrew MacLeod wrote:
On 4/11/25 10:27, Qing Zhao wrote:
On Apr 10, 2025, at 11:12, Martin Uecker wrote:
Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar:
On 2025-04-10 10:50, Andrew MacLeod wrote:
It
> On Apr 11, 2025, at 10:42, Andrew MacLeod wrote:
>
>
> On 4/11/25 10:27, Qing Zhao wrote:
>>
>>> On Apr 10, 2025, at 11:12, Martin Uecker wrote:
>>>
>>> Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar:
On 2025-04-10 10:50, Andrew MacLeod wrote:
> Its not c
Am Freitag, dem 11.04.2025 um 10:42 -0400 schrieb Andrew MacLeod:
> On 4/11/25 10:27, Qing Zhao wrote:
> >
> > > On Apr 10, 2025, at 11:12, Martin Uecker wrote:
> > >
> > > Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar:
> > > > On 2025-04-10 10:50, Andrew MacLeod wrote:
On 4/11/25 10:05, Qing Zhao wrote:
On Apr 10, 2025, at 10:55, Siddhesh Poyarekar wrote:
On 2025-04-10 10:50, Andrew MacLeod wrote:
Its not clear to me exactly what is being asked, but I think the suggestion is
that pointer references are being replaced with a builtin function called
.ACC
> On Apr 10, 2025, at 10:55, Siddhesh Poyarekar wrote:
>
> On 2025-04-10 10:50, Andrew MacLeod wrote:
>> Its not clear to me exactly what is being asked, but I think the suggestion
>> is that pointer references are being replaced with a builtin function called
>> .ACCESS_WITH_SIZE ?and I
> On Apr 10, 2025, at 11:12, Martin Uecker wrote:
>
> Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar:
>> On 2025-04-10 10:50, Andrew MacLeod wrote:
>>> Its not clear to me exactly what is being asked, but I think the
>>> suggestion is that pointer references are being
> On Apr 8, 2025, at 13:13, Siddhesh Poyarekar wrote:
>
> On 2025-04-08 12:41, Qing Zhao wrote:
>> For the following small example:
>> [ counted_by_whole]$ cat t.c
>> #include
>> #include
>> struct annotated {
>> size_t count;
>> char other;
>> char array[] __attribute__((counted_by (co
Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar:
> On 2025-04-10 10:50, Andrew MacLeod wrote:
> > Its not clear to me exactly what is being asked, but I think the
> > suggestion is that pointer references are being replaced with a builtin
> > function called .ACCESS_WITH_S
On 2025-04-10 11:12, Martin Uecker wrote:
range-ops is setup to pull range information from builtin functions
already in gimple-range-op.cc::
gimple_range_op_handler::maybe_builtin_call (). We'd just need to write
a handler for this new one. You can pull information from 2 operands
under normal
On 2025-04-10 10:50, Andrew MacLeod wrote:
Its not clear to me exactly what is being asked, but I think the
suggestion is that pointer references are being replaced with a builtin
function called .ACCESS_WITH_SIZE ? and I presume that builtin
function has some parameters that give you releva
On 4/8/25 13:13, Siddhesh Poyarekar wrote:
On 2025-04-08 12:41, Qing Zhao wrote:
For the following small example:
[ counted_by_whole]$ cat t.c
#include
#include
struct annotated {
size_t count;
char other;
char array[] __attribute__((counted_by (count)));
};
#define MAX(A, B) (A
On 2025-04-09 08:30, Qing Zhao wrote:
After expand phase, .ACCESS_WITH_SIZE will be replaced by its first argument.
And all the size expression before the call to .ACCESS_WITH_SIZE might be dead
code eliminated later in the RTL phases.
So, I don’t think there will be run-time overhead concern.
> On Apr 9, 2025, at 11:31, Siddhesh Poyarekar wrote:
>
> On 2025-04-09 08:30, Qing Zhao wrote:
>> After expand phase, .ACCESS_WITH_SIZE will be replaced by its first argument.
>> And all the size expression before the call to .ACCESS_WITH_SIZE might be
>> dead
>> code eliminated later in the
> On Apr 8, 2025, at 21:13, Siddhesh Poyarekar wrote:
>
> On 2025-04-08 15:22, Qing Zhao wrote:
>> Changing a pointer reference to a call to .ACCESS_WITH_SIZE will impact the
>> compiler optimization in two aspects:
>> 1. The new call site might become a barrier that prevents code movement
>
On 2025-04-08 15:22, Qing Zhao wrote:
Changing a pointer reference to a call to .ACCESS_WITH_SIZE will impact the
compiler optimization in two aspects:
1. The new call site might become a barrier that prevents code movement around
it.
Yeah, it's not a real problem IMO; it should only preven
27 matches
Mail list logo
