> -----Ursprüngliche Nachricht-----
> Von: David Brown <david.brown@xxxxxxxxxxxx>
> Gesendet: Samstag, 5. Dezember 2020 15:01
> An: Andrea Corallo <andrea.corallo@xxxxxxx>; Stefan Franke
> <s.franke@xxxxxxxxxxxx>
> Cc: gcc-help@xxxxxxxxxxx; stefan@xxxxxxxxx
> 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@xxxxxxxxxxxx> writes:
> >
> >>>> -----Ursprüngliche Nachricht-----
> >>>> Von: Gcc-help <gcc-help-bounces@xxxxxxxxxxx> Im Auftrag von
> Segher
> >>>> Boessenkool
> >>>> Gesendet: Freitag, 4. Dezember 2020 19:33
> >>>> An: Andrea Corallo <andrea.corallo@xxxxxxx>
> >>>> Cc: stefan@xxxxxxxxx; gcc-help@xxxxxxxxxxx
> >>>> 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@xxxxxxxxxxxxxxxxxxx> writes:
> >>>>>
> >>>>>> On Fri, Dec 04, 2020 at 10:52:17AM +0100, Andrea Corallo via
> >>> Gcc-help
> >>>> wrote:
> >>>>>>> stefan@xxxxxxxxx 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
