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

["Stefan Franke" <s.franke@bebbosoft.de>]

> -----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