Correct way to express to the compiler "this does not get clobbered"?

Correct way to express to the compiler "this does not get clobbered"?

[Andrea Corallo]

Hi all,

I've a piece of code that reduced looks like this:

#+begin_src C
typedef struct {
  void (*fun_ptr)(void);
} x_t;

x_t *x;

void
f (void)
{
  const x_t const *y = x;
  for (int i = 0; i < 1000; ++i)
    y->fun_ptr ();
}
#+end_src

What is the correct way (if any) to express to the compiler that the
value of y->fun_ptr does not get clobbered by the function call itself
so the corresponding load to obtain its value can be moved out of the
loop?

My understanding is that the const qualifier is more for diagnostic
reasons and is not sufficient for GCC to make this assumption.  OTOH I
cannot give 'fun_ptr' the attribute pure as it's not.

Thanks

  Andrea

Re: Correct way to express to the compiler "this does not get clobbered"?

[Richard Earnshaw]

On 03/12/2020 11:47, Andrea Corallo via Gcc-help wrote:
> Hi all,
> 
> I've a piece of code that reduced looks like this:
> 
> #+begin_src C
> typedef struct {
>   void (*fun_ptr)(void);
> } x_t;
> 
> x_t *x;
> 
> void
> f (void)
> {
>   const x_t const *y = x;
>   for (int i = 0; i < 1000; ++i)
>     y->fun_ptr ();
> }
> #+end_src
> 
> What is the correct way (if any) to express to the compiler that the
> value of y->fun_ptr does not get clobbered by the function call itself
> so the corresponding load to obtain its value can be moved out of the
> loop?
> 
> My understanding is that the const qualifier is more for diagnostic
> reasons and is not sufficient for GCC to make this assumption.  OTOH I
> cannot give 'fun_ptr' the attribute pure as it's not.
> 
> Thanks
> 
>   Andrea
> 

Why not just put the function pointer in a local variable?  Then the
compiler will know that the value can't change.

R.

Re: Correct way to express to the compiler "this does not get clobbered"?

[Andrea Corallo]

Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes:

> On 03/12/2020 11:47, Andrea Corallo via Gcc-help wrote:
>> Hi all,
>> 
>> I've a piece of code that reduced looks like this:
>> 
>> #+begin_src C
>> typedef struct {
>>   void (*fun_ptr)(void);
>> } x_t;
>> 
>> x_t *x;
>> 
>> void
>> f (void)
>> {
>>   const x_t const *y = x;
>>   for (int i = 0; i < 1000; ++i)
>>     y->fun_ptr ();
>> }
>> #+end_src
>> 
>> What is the correct way (if any) to express to the compiler that the
>> value of y->fun_ptr does not get clobbered by the function call itself
>> so the corresponding load to obtain its value can be moved out of the
>> loop?
>> 
>> My understanding is that the const qualifier is more for diagnostic
>> reasons and is not sufficient for GCC to make this assumption.  OTOH I
>> cannot give 'fun_ptr' the attribute pure as it's not.
>> 
>> Thanks
>> 
>>   Andrea
>> 
>
> Why not just put the function pointer in a local variable?  Then the
> compiler will know that the value can't change.

Hi Richard,

yeah that would do the job.

This is generated code and changing the code generator that way might
not be completely trivial (e.g. where is the best position to perform
the assignments to each local variable?).  Therefore before going for
this solution I'd like to be convinced there's no way to express this
directly to GCC.

  Andrea

Re: Correct way to express to the compiler "this does not get clobbered"?

[Richard Earnshaw]

On 03/12/2020 12:28, Andrea Corallo wrote:
> Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes:
> 
>> On 03/12/2020 11:47, Andrea Corallo via Gcc-help wrote:
>>> Hi all,
>>>
>>> I've a piece of code that reduced looks like this:
>>>
>>> #+begin_src C
>>> typedef struct {
>>>   void (*fun_ptr)(void);
>>> } x_t;
>>>
>>> x_t *x;
>>>
>>> void
>>> f (void)
>>> {
>>>   const x_t const *y = x;
>>>   for (int i = 0; i < 1000; ++i)
>>>     y->fun_ptr ();
>>> }
>>> #+end_src
>>>
>>> What is the correct way (if any) to express to the compiler that the
>>> value of y->fun_ptr does not get clobbered by the function call itself
>>> so the corresponding load to obtain its value can be moved out of the
>>> loop?
>>>
>>> My understanding is that the const qualifier is more for diagnostic
>>> reasons and is not sufficient for GCC to make this assumption.  OTOH I
>>> cannot give 'fun_ptr' the attribute pure as it's not.
>>>
>>> Thanks
>>>
>>>   Andrea
>>>
>>
>> Why not just put the function pointer in a local variable?  Then the
>> compiler will know that the value can't change.
> 
> Hi Richard,
> 
> yeah that would do the job.
> 
> This is generated code and changing the code generator that way might
> not be completely trivial (e.g. where is the best position to perform
> the assignments to each local variable?).  Therefore before going for
> this solution I'd like to be convinced there's no way to express this
> directly to GCC.
> 
>   Andrea
> 

Perhaps you could declare y with the restrict qualifier?  But that would
need to apply to all of *y, not just fun_ptr.

R.

Re: Correct way to express to the compiler "this does not get clobbered"?

[Andrea Corallo]

Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes:

[...]

> Perhaps you could declare y with the restrict qualifier?  But that would
> need to apply to all of *y, not just fun_ptr.

Having it applied to all *y would be perfect to me.

Unfortunatelly declaring y as:

x_t  * __restrict__ y = x;

does not influence the generated code :/

I though restrict is for pointer aliasing, maybe does not cover function
call clobbering?

  Andrea

Re: Correct way to express to the compiler "this does not get clobbered"?

[David Brown]

On 03/12/2020 12:47, Andrea Corallo via Gcc-help wrote:
> Hi all,
> 
> I've a piece of code that reduced looks like this:
> 
> #+begin_src C
> typedef struct {
>   void (*fun_ptr)(void);
> } x_t;
> 
> x_t *x;
> 
> void
> f (void)
> {
>   const x_t const *y = x;
>   for (int i = 0; i < 1000; ++i)
>     y->fun_ptr ();
> }
> #+end_src
> 
> What is the correct way (if any) to express to the compiler that the
> value of y->fun_ptr does not get clobbered by the function call itself
> so the corresponding load to obtain its value can be moved out of the
> loop?
> 
> My understanding is that the const qualifier is more for diagnostic
> reasons and is not sufficient for GCC to make this assumption.  OTOH I
> cannot give 'fun_ptr' the attribute pure as it's not.
> 

Imagine you also had :

x_t foox;

void foo1(void);
void foo2(void);

void foo1(void) {
	printf("foo1\n");
	foox.fun_ptr = foo2;
}

void foo2(void) {
	printf("foo2\n");
	foox.fun_ptr = foo1;
}

void test(void) {
	x = &foox;
	f();
}

As "f()" runs, the value of "y->fun_ptr" changes with each step as you
get alternating "foo1", "foo2" outputs.  Thus it is clear (I hope) that
the compiler cannot assume that "y->fun_ptr" is not clobbered by the
function call.

To get the effect you want, you'll have to change the code.  The easiest
way is (as has been suggested) to capture "y->fun_ptr" in a local
variable.  Alternatively you could capture "x" to a local variable, or
make it static, and ensure that its address doesn't escape - then the
compiler can tell that the fun_ptr() call can't change it.

Re: Correct way to express to the compiler "this does not get clobbered"?

[Andrea Corallo]

David Brown <david.brown@hesbynett.no> writes:

Hi David,

> As "f()" runs, the value of "y->fun_ptr" changes with each step as you
> get alternating "foo1", "foo2" outputs.  Thus it is clear (I hope) that
> the compiler cannot assume that "y->fun_ptr" is not clobbered by the
> function call.

Indeed that's clear.  The question is more if there's some way to express
this to the compiler qualifying the variables in discussion without
changing the structure of the code.  This because as I wrote may be not
trivial to modify the code generator for optimal results.

I understand this is probably not possible and there's no magic
attribute or qualifier to express this.

Thanks

  Andrea

Re: Correct way to express to the compiler "this does not get clobbered"?

[stefan]

Am 4. Dezember 2020 00:00:28 MEZ schrieb Andrea Corallo via Gcc-help <gcc-help@gcc.gnu.org>:
>David Brown <david.brown@hesbynett.no> writes:
>
>Hi David,
>
>> As "f()" runs, the value of "y->fun_ptr" changes with each step as
>you
>> get alternating "foo1", "foo2" outputs.  Thus it is clear (I hope)
>that
>> the compiler cannot assume that "y->fun_ptr" is not clobbered by the
>> function call.
>
>Indeed that's clear.  The question is more if there's some way to
>express
>this to the compiler qualifying the variables in discussion without
>changing the structure of the code.  This because as I wrote may be not
>trivial to modify the code generator for optimal results.
>
>I understand this is probably not possible and there's no magic
>attribute or qualifier to express this.
>
>Thanks
>
>  Andrea

IMHO it's a bug that const members referenced by a const pointer are reloaded inside the loop.

Regards

Stefan

Re: Correct way to express to the compiler "this does not get clobbered"?

[David Brown]

On 04/12/2020 00:00, Andrea Corallo wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
> Hi David,
> 
>> As "f()" runs, the value of "y->fun_ptr" changes with each step as you
>> get alternating "foo1", "foo2" outputs.  Thus it is clear (I hope) that
>> the compiler cannot assume that "y->fun_ptr" is not clobbered by the
>> function call.
> 
> Indeed that's clear.  The question is more if there's some way to express
> this to the compiler qualifying the variables in discussion without
> changing the structure of the code.  This because as I wrote may be not
> trivial to modify the code generator for optimal results.
> 
> I understand this is probably not possible and there's no magic
> attribute or qualifier to express this.
> 

In order to add a qualifier or attribute, you'd still need to change the 
code in some way.  Is it possible to make /some/ changes to the code 
generator, but not others?  (I appreciate that code generators can be 
difficult to change.)

On trick that sometimes works when you want to give the compiler more 
information is to use "if (!x) __builtin_unreachable();" as a way of 
saying "x is always true".  But I can't see any way that would help 
here, I'm afraid.

Re: Correct way to express to the compiler "this does not get clobbered"?

[Andrea Corallo]

stefan@franke.ms writes:

> Am 4. Dezember 2020 00:00:28 MEZ schrieb Andrea Corallo via Gcc-help <gcc-help@gcc.gnu.org>:
>>David Brown <david.brown@hesbynett.no> writes:
>>
>>Hi David,
>>
>>> As "f()" runs, the value of "y->fun_ptr" changes with each step as
>>you
>>> get alternating "foo1", "foo2" outputs.  Thus it is clear (I hope)
>>that
>>> the compiler cannot assume that "y->fun_ptr" is not clobbered by the
>>> function call.
>>
>>Indeed that's clear.  The question is more if there's some way to
>>express
>>this to the compiler qualifying the variables in discussion without
>>changing the structure of the code.  This because as I wrote may be not
>>trivial to modify the code generator for optimal results.
>>
>>I understand this is probably not possible and there's no magic
>>attribute or qualifier to express this.
>>
>>Thanks
>>
>>  Andrea
>
> IMHO it's a bug that const members referenced by a const pointer are reloaded inside the loop.

I might open a bug but my understanding is that const is generally
not used for optimizations.  Am I wrong?

  Andrea

Re: Correct way to express to the compiler "this does not get clobbered"?

[Andrea Corallo]

David Brown <david.brown@hesbynett.no> writes:

> On 04/12/2020 00:00, Andrea Corallo wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> Hi David,
>> 
>>> As "f()" runs, the value of "y->fun_ptr" changes with each step as you
>>> get alternating "foo1", "foo2" outputs.  Thus it is clear (I hope) that
>>> the compiler cannot assume that "y->fun_ptr" is not clobbered by the
>>> function call.
>> Indeed that's clear.  The question is more if there's some way to
>> express
>> this to the compiler qualifying the variables in discussion without
>> changing the structure of the code.  This because as I wrote may be not
>> trivial to modify the code generator for optimal results.
>> I understand this is probably not possible and there's no magic
>> attribute or qualifier to express this.
>> 
>
> In order to add a qualifier or attribute, you'd still need to change
> the code in some way.  Is it possible to make /some/ changes to the
> code generator, but not others?

What I said is that is possible to change the code generator, but adding
a qualifier or similar would be trivial, adding the local copy no.

I have many of these functions called through function pointer, each of
these can appear more then once in the code and I have non trivial
control flows (nested loops etc).  I could just emit all these copies at
the beginning of each function but this is suboptimal as non necessarly
they all will be used depending on the execution path, also for
scheduling reasons this would be not good.  The right thing would be to
load these pointers in the first common dominator of each basic block
requiring the use of each function pointer.  I can do it but is not a
good definition of trivial.

Thanks

  Andrea

Re: Correct way to express to the compiler "this does not get clobbered"?

[Segher Boessenkool]

On Fri, Dec 04, 2020 at 10:52:17AM +0100, Andrea Corallo via Gcc-help wrote:
> stefan@franke.ms writes:
> I might open a bug but my understanding is that const is generally
> not used for optimizations.  Am I wrong?

extern const int x = 42;
int f(void) { return x; }

The code generated for f does not load the value for x from memory: it
returns 42 always.


Segher

Re: Correct way to express to the compiler "this does not get clobbered"?

[Andrea Corallo]

Segher Boessenkool <segher@kernel.crashing.org> writes:

> On Fri, Dec 04, 2020 at 10:52:17AM +0100, Andrea Corallo via Gcc-help wrote:
>> stefan@franke.ms writes:
>> I might open a bug but my understanding is that const is generally
>> not used for optimizations.  Am I wrong?
>
> extern const int x = 42;
> int f(void) { return x; }
>
> The code generated for f does not load the value for x from memory: it
> returns 42 always.

Hi Segher,

Are you suggesting we should treat this as a bug?

  Andrea

Re: Correct way to express to the compiler "this does not get clobbered"?

[Segher Boessenkool]

On Fri, Dec 04, 2020 at 07:16:45PM +0100, Andrea Corallo via Gcc-help wrote:
> Segher Boessenkool <segher@kernel.crashing.org> writes:
> 
> > On Fri, Dec 04, 2020 at 10:52:17AM +0100, Andrea Corallo via Gcc-help wrote:
> >> stefan@franke.ms writes:
> >> I might open a bug but my understanding is that const is generally
> >> not used for optimizations.  Am I wrong?
> >
> > extern const int x = 42;
> > int f(void) { return x; }
> >
> > The code generated for f does not load the value for x from memory: it
> > returns 42 always.

> Are you suggesting we should treat this as a bug?

Huh?  No, I am just saying that const *is* used for optimisation, with a
dumb simple example.  Remove const from this code and you get different
generated machine code (that does load x from memory always).

If you think you have found a missing optimisation, please make a
self-contained demonstrator for that, and a file a PR?


Segher

Re: Correct way to express to the compiler "this does not get clobbered"?

[Andrea Corallo]

Segher Boessenkool <segher@kernel.crashing.org> writes:

> On Fri, Dec 04, 2020 at 07:16:45PM +0100, Andrea Corallo via Gcc-help wrote:
>> Segher Boessenkool <segher@kernel.crashing.org> writes:
>> 
>> > On Fri, Dec 04, 2020 at 10:52:17AM +0100, Andrea Corallo via Gcc-help wrote:
>> >> stefan@franke.ms writes:
>> >> I might open a bug but my understanding is that const is generally
>> >> not used for optimizations.  Am I wrong?
>> >
>> > extern const int x = 42;
>> > int f(void) { return x; }
>> >
>> > The code generated for f does not load the value for x from memory: it
>> > returns 42 always.
>
>> Are you suggesting we should treat this as a bug?
>
> Huh?

Sorry for the miscommunication, with "this" I meant the code of the
original question of this thread.

> No, I am just saying that const *is* used for optimisation, with a
> dumb simple example.  Remove const from this code and you get different
> generated machine code (that does load x from memory always).
>
> If you think you have found a missing optimisation, please make a
> self-contained demonstrator for that, and a file a PR?

All righ I'll do it.

  Andrea

AW: Correct way to express to the compiler "this does not get clobbered"?

[Stefan Franke]

> > -----Ursprüngliche Nachricht-----
> > Von: Gcc-help <gcc-help-bounces@gcc.gnu.org> Im Auftrag von Segher
> > Boessenkool
> > Gesendet: Freitag, 4. Dezember 2020 19:33
> > An: Andrea Corallo <andrea.corallo@arm.com>
> > Cc: stefan@franke.ms; gcc-help@gcc.gnu.org
> > Betreff: Re: Correct way to express to the compiler "this does not get
> > clobbered"?
> >
> > On Fri, Dec 04, 2020 at 07:16:45PM +0100, Andrea Corallo via Gcc-help
> wrote:
> > > Segher Boessenkool <segher@kernel.crashing.org> writes:
> > >
> > > > On Fri, Dec 04, 2020 at 10:52:17AM +0100, Andrea Corallo via
> Gcc-help
> > wrote:
> > > >> stefan@franke.ms writes:
> > > >> I might open a bug but my understanding is that const is
> > > >> generally not used for optimizations.  Am I wrong?
> > > >
> > > > extern const int x = 42;
> > > > int f(void) { return x; }
> > > >
> > > > The code generated for f does not load the value for x from memory:
> > > > it returns 42 always.
> >
> > > Are you suggesting we should treat this as a bug?
> >
> > Huh?  No, I am just saying that const *is* used for optimisation, with
> > a
> dumb
> > simple example.  Remove const from this code and you get different
> > generated machine code (that does load x from memory always).
> >
> > If you think you have found a missing optimisation, please make a
> > self- contained demonstrator for that, and a file a PR?
> >
> >
> > Segher

IMHO it's the cprop pass which should get enhanced.

Stefan

Re: AW: Correct way to express to the compiler "this does not get clobbered"?

[Andrea Corallo]

"Stefan Franke" <s.franke@bebbosoft.de> writes:

>> > -----Ursprüngliche Nachricht-----
>> > Von: Gcc-help <gcc-help-bounces@gcc.gnu.org> Im Auftrag von Segher
>> > Boessenkool
>> > Gesendet: Freitag, 4. Dezember 2020 19:33
>> > An: Andrea Corallo <andrea.corallo@arm.com>
>> > Cc: stefan@franke.ms; gcc-help@gcc.gnu.org
>> > Betreff: Re: Correct way to express to the compiler "this does not get
>> > clobbered"?
>> >
>> > On Fri, Dec 04, 2020 at 07:16:45PM +0100, Andrea Corallo via Gcc-help
>> wrote:
>> > > Segher Boessenkool <segher@kernel.crashing.org> writes:
>> > >
>> > > > On Fri, Dec 04, 2020 at 10:52:17AM +0100, Andrea Corallo via
>> Gcc-help
>> > wrote:
>> > > >> stefan@franke.ms writes:
>> > > >> I might open a bug but my understanding is that const is
>> > > >> generally not used for optimizations.  Am I wrong?
>> > > >
>> > > > extern const int x = 42;
>> > > > int f(void) { return x; }
>> > > >
>> > > > The code generated for f does not load the value for x from memory:
>> > > > it returns 42 always.
>> >
>> > > Are you suggesting we should treat this as a bug?
>> >
>> > Huh?  No, I am just saying that const *is* used for optimisation, with
>> > a
>> dumb
>> > simple example.  Remove const from this code and you get different
>> > generated machine code (that does load x from memory always).
>> >
>> > If you think you have found a missing optimisation, please make a
>> > self- contained demonstrator for that, and a file a PR?
>> >
>> >
>> > Segher
>
> IMHO it's the cprop pass which should get enhanced.
>
> Stefan

Hi Stefan,

IIUC declaring a pointer to constant prevents the pointer to be used in
order to modify what is pointing to.

But in this case (the original example) it does not prevent the function
being called to modify that piece of memory (the one pointed by y).

Therefore I believe this is not a bug.

  Andrea

Re: Correct way to express to the compiler "this does not get clobbered"?

[Liu Hao]

[-- Attachment #1.1: Type: text/plain, Size: 1510 bytes --]

在 2020/12/3 下午7:47, Andrea Corallo via Gcc-help 写道:
> Hi all,
> 
> I've a piece of code that reduced looks like this:
> 
> #+begin_src C
> typedef struct {
>   void (*fun_ptr)(void);
> } x_t;
> 
> x_t *x;
> 
> void
> f (void)
> {
>   const x_t const *y = x;
>   for (int i = 0; i < 1000; ++i)
>     y->fun_ptr ();
> }
> #+end_src
> 
> What is the correct way (if any) to express to the compiler that the
> value of y->fun_ptr does not get clobbered by the function call itself
> so the corresponding load to obtain its value can be moved out of the
> loop?


How about:

```c
void
f (void)
{
  int i;

  for (__auto_type p = (     // warning: use of GCC extension
              (i = 0),       // set `i` to zero
              y->fun_ptr);   // warning: abuse of comma operator
           i < 1000; ++i)
    p ();
}
```

You would only ever need one `i` in each function, so it'd not be very complicated. The scope of `p`
is limited to the enclosing `for` statement.

> 
> My understanding is that the const qualifier is more for diagnostic
> reasons and is not sufficient for GCC to make this assumption.  OTOH I
> cannot give 'fun_ptr' the attribute pure as it's not.
> 

`const` may be used for optimization only if it causes an object to be declared `const`. Something
such as `const int x = 42;` is known by the compiler to be immutable, but the result of an
indirection through a pointer might not be.



-- 
Best regards,
LH_Mouse


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: AW: Correct way to express to the compiler "this does not get clobbered"?

[David Brown]

On 04/12/2020 23:52, Andrea Corallo via Gcc-help wrote:
> "Stefan Franke" <s.franke@bebbosoft.de> writes:
> 
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Gcc-help <gcc-help-bounces@gcc.gnu.org> Im Auftrag von Segher
>>>> Boessenkool
>>>> Gesendet: Freitag, 4. Dezember 2020 19:33
>>>> An: Andrea Corallo <andrea.corallo@arm.com>
>>>> Cc: stefan@franke.ms; gcc-help@gcc.gnu.org
>>>> Betreff: Re: Correct way to express to the compiler "this does not get
>>>> clobbered"?
>>>>
>>>> On Fri, Dec 04, 2020 at 07:16:45PM +0100, Andrea Corallo via Gcc-help
>>> wrote:
>>>>> Segher Boessenkool <segher@kernel.crashing.org> writes:
>>>>>
>>>>>> On Fri, Dec 04, 2020 at 10:52:17AM +0100, Andrea Corallo via
>>> Gcc-help
>>>> wrote:
>>>>>>> stefan@franke.ms writes:
>>>>>>> I might open a bug but my understanding is that const is
>>>>>>> generally not used for optimizations.  Am I wrong?
>>>>>>
>>>>>> extern const int x = 42;
>>>>>> int f(void) { return x; }
>>>>>>
>>>>>> The code generated for f does not load the value for x from memory:
>>>>>> it returns 42 always.
>>>>
>>>>> Are you suggesting we should treat this as a bug?
>>>>
>>>> Huh?  No, I am just saying that const *is* used for optimisation, with
>>>> a
>>> dumb
>>>> simple example.  Remove const from this code and you get different
>>>> generated machine code (that does load x from memory always).
>>>>
>>>> If you think you have found a missing optimisation, please make a
>>>> self- contained demonstrator for that, and a file a PR?
>>>>
>>>>
>>>> Segher
>>
>> IMHO it's the cprop pass which should get enhanced.
>>
>> Stefan
> 
> Hi Stefan,
> 
> IIUC declaring a pointer to constant prevents the pointer to be used in
> order to modify what is pointing to.
> 
> But in this case (the original example) it does not prevent the function
> being called to modify that piece of memory (the one pointed by y).
> 
> Therefore I believe this is not a bug.
> 
>   Andrea
> 

That is, AFAIUI, correct.

The case of "extern const int x = 42;" above is very different - here
the object "x" is /defined/ as a const, and therefore the compiler knows
it cannot ever be changed (or rather, any attempts to change it are
undefined behaviour).  But if you make a const pointer to something, you
are merely saying that /you/ won't change the object (via that pointer).
 There is no way in C to say that there can't be anything else that
changes the object.

AW: AW: Correct way to express to the compiler "this does not get clobbered"?

[Stefan Franke]

> -----Ursprüngliche Nachricht-----
> Von: David Brown <david.brown@hesbynett.no>
> Gesendet: Samstag, 5. Dezember 2020 15:01
> An: Andrea Corallo <andrea.corallo@arm.com>; Stefan Franke
> <s.franke@bebbosoft.de>
> Cc: gcc-help@gcc.gnu.org; stefan@franke.ms
> Betreff: Re: AW: Correct way to express to the compiler "this does not get
> clobbered"?
> 
> On 04/12/2020 23:52, Andrea Corallo via Gcc-help wrote:
> > "Stefan Franke" <s.franke@bebbosoft.de> writes:
> >
> >>>> -----Ursprüngliche Nachricht-----
> >>>> Von: Gcc-help <gcc-help-bounces@gcc.gnu.org> Im Auftrag von
> Segher
> >>>> Boessenkool
> >>>> Gesendet: Freitag, 4. Dezember 2020 19:33
> >>>> An: Andrea Corallo <andrea.corallo@arm.com>
> >>>> Cc: stefan@franke.ms; gcc-help@gcc.gnu.org
> >>>> Betreff: Re: Correct way to express to the compiler "this does not
> >>>> get clobbered"?
> >>>>
> >>>> On Fri, Dec 04, 2020 at 07:16:45PM +0100, Andrea Corallo via
> >>>> Gcc-help
> >>> wrote:
> >>>>> Segher Boessenkool <segher@kernel.crashing.org> writes:
> >>>>>
> >>>>>> On Fri, Dec 04, 2020 at 10:52:17AM +0100, Andrea Corallo via
> >>> Gcc-help
> >>>> wrote:
> >>>>>>> stefan@franke.ms writes:
> >>>>>>> I might open a bug but my understanding is that const is
> >>>>>>> generally not used for optimizations.  Am I wrong?
> >>>>>>
> >>>>>> extern const int x = 42;
> >>>>>> int f(void) { return x; }
> >>>>>>
> >>>>>> The code generated for f does not load the value for x from
> memory:
> >>>>>> it returns 42 always.
> >>>>
> >>>>> Are you suggesting we should treat this as a bug?
> >>>>
> >>>> Huh?  No, I am just saying that const *is* used for optimisation,
> >>>> with a
> >>> dumb
> >>>> simple example.  Remove const from this code and you get different
> >>>> generated machine code (that does load x from memory always).
> >>>>
> >>>> If you think you have found a missing optimisation, please make a
> >>>> self- contained demonstrator for that, and a file a PR?
> >>>>
> >>>>
> >>>> Segher
> >>
> >> IMHO it's the cprop pass which should get enhanced.
> >>
> >> Stefan
> >
> > Hi Stefan,
> >
> > IIUC declaring a pointer to constant prevents the pointer to be used
> > in order to modify what is pointing to.
> >
> > But in this case (the original example) it does not prevent the
> > function being called to modify that piece of memory (the one pointed by
> y).
> >
> > Therefore I believe this is not a bug.
> >
> >   Andrea
> >
> 
> That is, AFAIUI, correct.
> 
> The case of "extern const int x = 42;" above is very different - here the object
> "x" is /defined/ as a const, and therefore the compiler knows it cannot ever
> be changed (or rather, any attempts to change it are undefined behaviour).
> But if you make a const pointer to something, you are merely saying that
> /you/ won't change the object (via that pointer).
>  There is no way in C to say that there can't be anything else that changes the
> object.
> 

I disagree:

typedef struct {
   void (* const fun_ptr)(void);
   const long x;
 } x_t;

Declares that fun_ptr and x both are const and cannot change. So these const value can safely be propagated out of loops if the pointer to is also const and can't change. The current compiler simply ignores that knowledge.

I cannot judge if this is a bug or a not implemented feature. But in the current implementation only the c/c++ parser cares about const whereas the compiler passes do not check constness.

Regards

Stefan

Re: AW: Correct way to express to the compiler "this does not get clobbered"?

[Andrea Corallo]

David Brown <david.brown@hesbynett.no> writes:

[...]

>  There is no way in C to say that there can't be anything else that
> changes the object.

I think it would be nice to have, if not in C at least in GCC.

  Andrea

Re: AW: AW: Correct way to express to the compiler "this does not get clobbered"?

[Andrea Corallo]

"Stefan Franke" <s.franke@bebbosoft.de> writes:

[...]

> I disagree:
>
> typedef struct {
>    void (* const fun_ptr)(void);
>    const long x;
>  } x_t;
>
> Declares that fun_ptr and x both are const and cannot change. So these const value can safely be propagated out of loops if the pointer to is also const and can't change. The current compiler simply ignores that knowledge.
>
> I cannot judge if this is a bug or a not implemented feature. But in the current implementation only the c/c++ parser cares about const whereas the compiler passes do not check constness.

You might be right if you change the code this way, but to begin with
how do you set 'fun_ptr' if the only way to access it is through a
pointer to const?  I suspect this is not very much a realistic case.

  Andrea

Re: AW: AW: Correct way to express to the compiler "this does not get clobbered"?

[David Brown]

On 05/12/2020 15:17, Stefan Franke wrote:
> 
> 
>> -----Ursprüngliche Nachricht-----
>> Von: David Brown <david.brown@hesbynett.no>
>> Gesendet: Samstag, 5. Dezember 2020 15:01
>> An: Andrea Corallo <andrea.corallo@arm.com>; Stefan Franke
>> <s.franke@bebbosoft.de>
>> Cc: gcc-help@gcc.gnu.org; stefan@franke.ms
>> Betreff: Re: AW: Correct way to express to the compiler "this does not get
>> clobbered"?
>>
>> On 04/12/2020 23:52, Andrea Corallo via Gcc-help wrote:
>>> "Stefan Franke" <s.franke@bebbosoft.de> writes:
>>>
>>>>>> -----Ursprüngliche Nachricht-----
>>>>>> Von: Gcc-help <gcc-help-bounces@gcc.gnu.org> Im Auftrag von
>> Segher
>>>>>> Boessenkool
>>>>>> Gesendet: Freitag, 4. Dezember 2020 19:33
>>>>>> An: Andrea Corallo <andrea.corallo@arm.com>
>>>>>> Cc: stefan@franke.ms; gcc-help@gcc.gnu.org
>>>>>> Betreff: Re: Correct way to express to the compiler "this does not
>>>>>> get clobbered"?
>>>>>>
>>>>>> On Fri, Dec 04, 2020 at 07:16:45PM +0100, Andrea Corallo via
>>>>>> Gcc-help
>>>>> wrote:
>>>>>>> Segher Boessenkool <segher@kernel.crashing.org> writes:
>>>>>>>
>>>>>>>> On Fri, Dec 04, 2020 at 10:52:17AM +0100, Andrea Corallo via
>>>>> Gcc-help
>>>>>> wrote:
>>>>>>>>> stefan@franke.ms writes:
>>>>>>>>> I might open a bug but my understanding is that const is
>>>>>>>>> generally not used for optimizations.  Am I wrong?
>>>>>>>>
>>>>>>>> extern const int x = 42;
>>>>>>>> int f(void) { return x; }
>>>>>>>>
>>>>>>>> The code generated for f does not load the value for x from
>> memory:
>>>>>>>> it returns 42 always.
>>>>>>
>>>>>>> Are you suggesting we should treat this as a bug?
>>>>>>
>>>>>> Huh?  No, I am just saying that const *is* used for optimisation,
>>>>>> with a
>>>>> dumb
>>>>>> simple example.  Remove const from this code and you get different
>>>>>> generated machine code (that does load x from memory always).
>>>>>>
>>>>>> If you think you have found a missing optimisation, please make a
>>>>>> self- contained demonstrator for that, and a file a PR?
>>>>>>
>>>>>>
>>>>>> Segher
>>>>
>>>> IMHO it's the cprop pass which should get enhanced.
>>>>
>>>> Stefan
>>>
>>> Hi Stefan,
>>>
>>> IIUC declaring a pointer to constant prevents the pointer to be used
>>> in order to modify what is pointing to.
>>>
>>> But in this case (the original example) it does not prevent the
>>> function being called to modify that piece of memory (the one pointed by
>> y).
>>>
>>> Therefore I believe this is not a bug.
>>>
>>>   Andrea
>>>
>>
>> That is, AFAIUI, correct.
>>
>> The case of "extern const int x = 42;" above is very different - here the object
>> "x" is /defined/ as a const, and therefore the compiler knows it cannot ever
>> be changed (or rather, any attempts to change it are undefined behaviour).
>> But if you make a const pointer to something, you are merely saying that
>> /you/ won't change the object (via that pointer).
>>  There is no way in C to say that there can't be anything else that changes the
>> object.
>>
> 
> I disagree:
> 
> typedef struct {
>    void (* const fun_ptr)(void);
>    const long x;
>  } x_t;
> 
> Declares that fun_ptr and x both are const and cannot change. So these const value can safely be propagated out of loops if the pointer to is also const and can't change. The current compiler simply ignores that knowledge.
> 
> I cannot judge if this is a bug or a not implemented feature. But in the current implementation only the c/c++ parser cares about const whereas the compiler passes do not check constness.
> 
> Regards
> 
> Stefan
> 

Pointer declarations cannot tell the compiler that something never
changes.  All you can do with a pointer declaration is promise that
/you/ will not change the object, at least not via that declaration.

This is because you can assign a pointer-to-const to point to a
non-const object.  The "true" constness of an object comes from its
definition, not from how you use it.

Re: AW: Correct way to express to the compiler "this does not get clobbered"?

[David Brown]

On 05/12/2020 18:29, Andrea Corallo via Gcc-help wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
> [...]
> 
>>  There is no way in C to say that there can't be anything else that
>> changes the object.
> 
> I think it would be nice to have, if not in C at least in GCC.
> 
>   Andrea
> 

Agreed.  But I think there are so many possible things about constness
that it would be nice to have, that it could quickly get out of hand.

I'd really like a way to tell the compiler that a given object gets set
once during some early function in the program, and can never change
after that.  But I can't think of any good syntax for that.

Re: AW: Correct way to express to the compiler "this does not get clobbered"?

[Jonathan Wakely]

On Sat, 5 Dec 2020, 19:08 David Brown, <david.brown@hesbynett.no> wrote:

> On 05/12/2020 18:29, Andrea Corallo via Gcc-help wrote:
> > David Brown <david.brown@hesbynett.no> writes:
> >
> > [...]
> >
> >>  There is no way in C to say that there can't be anything else that
> >> changes the object.
> >
> > I think it would be nice to have, if not in C at least in GCC.
> >
> >   Andrea
> >
>
> Agreed.  But I think there are so many possible things about constness
> that it would be nice to have, that it could quickly get out of hand.
>
> I'd really like a way to tell the compiler that a given object gets set
> once during some early function in the program, and can never change
> after that.  But I can't think of any good syntax for that.
>

An attribute on the assignment statement (or function) that sets it could
say it's the last write to the object.

That seems appropriate for an attribute, since it's only an optimisation
hint and a conforming compiler could choose to ignore the hint without
changing the meaning of the code. (That's the rule of thumb for whether to
use [[attribute]] syntax in ISO C++).

AW: AW: AW: Correct way to express to the compiler "this does not get clobbered"?

[Stefan Franke]

> -----Ursprüngliche Nachricht-----
> Von: David Brown <david.brown@hesbynett.no>
> Gesendet: Samstag, 5. Dezember 2020 20:03
> An: stefan@franke.ms; gcc-help@gcc.gnu.org
> Betreff: Re: AW: AW: Correct way to express to the compiler "this does not
> get clobbered"?
> 
> On 05/12/2020 15:17, Stefan Franke wrote:
> >
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: David Brown <david.brown@hesbynett.no>
> >> Gesendet: Samstag, 5. Dezember 2020 15:01
> >> An: Andrea Corallo <andrea.corallo@arm.com>; Stefan Franke
> >> <s.franke@bebbosoft.de>
> >> Cc: gcc-help@gcc.gnu.org; stefan@franke.ms
> >> Betreff: Re: AW: Correct way to express to the compiler "this does
> >> not get clobbered"?
> >>
> >> On 04/12/2020 23:52, Andrea Corallo via Gcc-help wrote:
> >>> "Stefan Franke" <s.franke@bebbosoft.de> writes:
> >>>
> >>>>>> -----Ursprüngliche Nachricht-----
> >>>>>> Von: Gcc-help <gcc-help-bounces@gcc.gnu.org> Im Auftrag von
> >> Segher
> >>>>>> Boessenkool
> >>>>>> Gesendet: Freitag, 4. Dezember 2020 19:33
> >>>>>> An: Andrea Corallo <andrea.corallo@arm.com>
> >>>>>> Cc: stefan@franke.ms; gcc-help@gcc.gnu.org
> >>>>>> Betreff: Re: Correct way to express to the compiler "this does
> >>>>>> not get clobbered"?
> >>>>>>
> >>>>>> On Fri, Dec 04, 2020 at 07:16:45PM +0100, Andrea Corallo via
> >>>>>> Gcc-help
> >>>>> wrote:
> >>>>>>> Segher Boessenkool <segher@kernel.crashing.org> writes:
> >>>>>>>
> >>>>>>>> On Fri, Dec 04, 2020 at 10:52:17AM +0100, Andrea Corallo via
> >>>>> Gcc-help
> >>>>>> wrote:
> >>>>>>>>> stefan@franke.ms writes:
> >>>>>>>>> I might open a bug but my understanding is that const is
> >>>>>>>>> generally not used for optimizations.  Am I wrong?
> >>>>>>>>
> >>>>>>>> extern const int x = 42;
> >>>>>>>> int f(void) { return x; }
> >>>>>>>>
> >>>>>>>> The code generated for f does not load the value for x from
> >> memory:
> >>>>>>>> it returns 42 always.
> >>>>>>
> >>>>>>> Are you suggesting we should treat this as a bug?
> >>>>>>
> >>>>>> Huh?  No, I am just saying that const *is* used for optimisation,
> >>>>>> with a
> >>>>> dumb
> >>>>>> simple example.  Remove const from this code and you get
> >>>>>> different generated machine code (that does load x from memory
> always).
> >>>>>>
> >>>>>> If you think you have found a missing optimisation, please make a
> >>>>>> self- contained demonstrator for that, and a file a PR?
> >>>>>>
> >>>>>>
> >>>>>> Segher
> >>>>
> >>>> IMHO it's the cprop pass which should get enhanced.
> >>>>
> >>>> Stefan
> >>>
> >>> Hi Stefan,
> >>>
> >>> IIUC declaring a pointer to constant prevents the pointer to be used
> >>> in order to modify what is pointing to.
> >>>
> >>> But in this case (the original example) it does not prevent the
> >>> function being called to modify that piece of memory (the one
> >>> pointed by
> >> y).
> >>>
> >>> Therefore I believe this is not a bug.
> >>>
> >>>   Andrea
> >>>
> >>
> >> That is, AFAIUI, correct.
> >>
> >> The case of "extern const int x = 42;" above is very different - here
> >> the object "x" is /defined/ as a const, and therefore the compiler
> >> knows it cannot ever be changed (or rather, any attempts to change it
> >> are undefined behaviour).
> >> But if you make a const pointer to something, you are merely saying
> >> that /you/ won't change the object (via that pointer).
> >>  There is no way in C to say that there can't be anything else that
> >> changes the object.
> >>
> >
> > I disagree:
> >
> > typedef struct {
> >    void (* const fun_ptr)(void);
> >    const long x;
> >  } x_t;
> >
> > Declares that fun_ptr and x both are const and cannot change. So these
> > const value can safely be propagated out of loops if the pointer to is
> > also const and can't change. The current compiler simply ignores that
> > knowledge.
> >
> > I cannot judge if this is a bug or a not implemented feature. But in
> > the current implementation only the c/c++ parser cares about const
> > whereas the compiler passes do not check constness.
> >
> > Regards
> >
> > Stefan
> >
> 
> Pointer declarations cannot tell the compiler that something never changes.
> All you can do with a pointer declaration is promise that /you/ will not change
> the object, at least not via that declaration.
> 
> This is because you can assign a pointer-to-const to point to a non-const
> object.  The "true" constness of an object comes from its definition, not from
> how you use it.


If you look at the type you'll notice the const qualifier.

With two changes to expr.c that info can be used and the compiler pulls it out of the loop.

One here to mark the const pointer as unchanging:

      if (exp && exp->ssa_name.typed.type->base.constant_flag)
	decl_rtl->unchanging = 1;
...
      /* Show we haven't gotten RTL for this yet.  */

And another one there :

	if (MEM_P (op0) && exp->base.code == COMPONENT_REF && XEXP (op0, 0)->unchanging
	    && ((exp)->exp.operands[1])->base.readonly_flag)
	  {
	    if (op0 == orig_op0)
	      op0 = copy_rtx (op0);

	    MEM_READONLY_P(op0) = 1;
	  }
...
	/* In cases where an aligned union has an unaligned object

Marks the mem as read only. And the code gets enhanced.

That's not fully correct, and just a hack, but it shows that there is present information which could be used to enhance the code generation.


/Cheers

Stefan

Re: AW: AW: Correct way to express to the compiler "this does not get clobbered"?

[Segher Boessenkool]

On Sat, Dec 05, 2020 at 07:10:08PM +0100, Andrea Corallo via Gcc-help wrote:
> "Stefan Franke" <s.franke@bebbosoft.de> writes:
> > typedef struct {
> >    void (* const fun_ptr)(void);
> >    const long x;
> >  } x_t;
> >
> > Declares that fun_ptr and x both are const and cannot change. So these const value can safely be propagated out of loops if the pointer to is also const and can't change. The current compiler simply ignores that knowledge.
> >
> > I cannot judge if this is a bug or a not implemented feature. But in the current implementation only the c/c++ parser cares about const whereas the compiler passes do not check constness.
> 
> You might be right if you change the code this way, but to begin with
> how do you set 'fun_ptr' if the only way to access it is through a
> pointer to const?  I suspect this is not very much a realistic case.

void f(void)
{
	x_t x = { .x = 42; .fun_ptr = f; };

...

etc.

The variable dies when the function returns, but other than that this
works fine.


Segher