From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bebbosoft.de (serveronline.org [78.46.86.77]) by sourceware.org (Postfix) with ESMTPS id 463E23857831 for ; Sun, 6 Dec 2020 11:29:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 463E23857831 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=bebbosoft.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=s.franke@bebbosoft.de Received: from ZETRA (x590fee29.dyn.telefonica.de [89.15.238.41]) by serveronline.org (BEJY V1.6.12-SNAPSHOT (c) 2000-2019 by BebboSoft, Stefan "Bebbo" Franke, all rights reserved) with SMTP id 17637cff94ec6cac25fd501580c from s.franke@bebbosoft.de for gcc-help@gcc.gnu.org; Sun, 06 Dec 2020 12:29:05 +0100 Reply-To: From: "Stefan Franke" To: References: <32b3c0a3-9917-2b92-de59-1d6a14ecd8f8@hesbynett.no> <20201204172721.GM2672@gate.crashing.org> <20201204183317.GO2672@gate.crashing.org> <017701d6ca6d$7dc8dc90$795a95b0$@bebbosoft.de> <017801d6ca6f$56fed450$04fc7cf0$@bebbosoft.de> <01c901d6cb11$5c31abd0$14950370$@bebbosoft.de> <35f7386c-a8db-4c48-19ce-ffc26d8feb23@hesbynett.no> In-Reply-To: <35f7386c-a8db-4c48-19ce-ffc26d8feb23@hesbynett.no> Subject: AW: AW: AW: Correct way to express to the compiler "this does not get clobbered"? Date: Sun, 6 Dec 2020 12:29:04 +0100 Message-ID: <028e01d6cbc3$012cc1e0$038645a0$@bebbosoft.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKMzJI1tuTBQV2C9TTl/pE5jXQhpwLY7cDyATYuCFUCIfenVgIhR1yTARR7GL8CajVR2gKrXKjYArYl/0sCAbDN5QJnVyRuAgswxiABw0c5fwHkzvuBp6Ny/5A= Content-Language: de X-Spam-Status: No, score=1.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2020 11:29:09 -0000 > -----Urspr=C3=BCngliche Nachricht----- > Von: David Brown > 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"? >=20 > On 05/12/2020 15:17, Stefan Franke wrote: > > > > > >> -----Urspr=C3=BCngliche Nachricht----- > >> Von: David Brown > >> Gesendet: Samstag, 5. Dezember 2020 15:01 > >> An: Andrea Corallo ; Stefan Franke > >> > >> 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" writes: > >>> > >>>>>> -----Urspr=C3=BCngliche Nachricht----- > >>>>>> Von: Gcc-help Im Auftrag von > >> Segher > >>>>>> Boessenkool > >>>>>> Gesendet: Freitag, 4. Dezember 2020 19:33 > >>>>>> An: Andrea Corallo > >>>>>> 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 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 =3D 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 =3D 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 > > >=20 > 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. >=20 > 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 =3D 1; ... /* Show we haven't gotten RTL for this yet. */ And another one there : if (MEM_P (op0) && exp->base.code =3D=3D COMPONENT_REF && XEXP (op0, = 0)->unchanging && ((exp)->exp.operands[1])->base.readonly_flag) { if (op0 =3D=3D orig_op0) op0 =3D copy_rtx (op0); MEM_READONLY_P(op0) =3D 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