I’m not so sure about this case, as a smart compiler might decide the loop warrants alias checking, and then might only perform a single load and store and perform all of the computations in registers (or unroll them completely).
I am not aware of compilers doing this today, but they certainly could. > On Nov 30, 2018, at 12:13 PM, Burak Serdar <bser...@ieee.org> wrote: > > On Fri, Nov 30, 2018 at 11:09 AM Jakob Borg <ja...@kastelo.net > <mailto:ja...@kastelo.net>> wrote: >> >> This should only be valid for a loop that doesn’t include any function >> calls, or if the compiler can prove that said function calls don’t involve >> any synchronization primitives anywhere in the possible call stack. > > ...or any potential pointer aliases: > > p:=&value > q:=&value > > for ... { > total+=*p > (*q)++ > } > >> >> So maybe it’s optimized in >> >> for … { >> total += *p >> } >> >> but I wouldn’t bet on it in >> >> for … { >> total += *p >> foo() >> } >> >> //jb >> >> On 30 Nov 2018, at 19:01, robert engels <reng...@ix.netcom.com> wrote: >> >> I would think the compiler would be free to optimize this as a single load >> outside the loop - as Go has no volatile declaration (to inform the compiler >> that some other thread might of changed the value of *p) >> >> On Nov 30, 2018, at 11:58 AM, robert engels <reng...@ix.netcom.com> wrote: >> >> It’s as simple as: >> >> var count = 1 >> var p = &count >> >> func X() { >> total :=0 >> >> for i:=0; i <1000000;i++ { >> total = total + *p >> } >> } >> >> no ? >> >> On Nov 30, 2018, at 11:48 AM, Mark Volkmann <r.mark.volkm...@gmail.com> >> wrote: >> >> I think I failed to come up with a good code example. But suppose I need to >> do something with a pointer inside a loop that really does require >> dereferencing it and the pointer never changes inside the loop. In that case >> will the Go compiler optimize that so the dereference doesn't happen in each >> loop iteration? >> >> On Fri, Nov 30, 2018 at 11:36 AM Jan Mercl <0xj...@gmail.com> wrote: >>> >>> >>> On Fri, Nov 30, 2018 at 6:16 PM Mark Volkmann <r.mark.volkm...@gmail.com> >>> wrote: >>> >>>> Will the Go compiler optimize the pointer dereference so it doesn't happen >>>> in every loop iteration? If not, is it common practice to do that outside >>>> the loop like this? >>>> >>>> myValue := *myPtr >>>> for _, v := range values { >>>> fmt.Printf("%v %v\n", myValue, v) >>>> } >>> >>> There's no pointer dereference inside the loop. But there's an allocation >>> inside the loop, on every iteration, that puts a pointer to a copy of >>> myValue into an interface{} that's passed to fmt.Printf. The allocation can >>> be probably avoided: >>> >>> myValue := interface{}(*myPtr) >>> for _, v := range values { >>> fmt.Printf("%v %v\n", myValue, v) >>> } >>> >>> But the %v verb handle pointers in many cases well. If that holds for the >>> type of *myPtr then simply: >>> >>> for _, v := range values { >>> fmt.Printf("%v %v\n", myPtr, v) >>> } >>> >>> is what could be good enough. >>> >>> -- >>> >>> -j >> >> >> >> -- >> R. Mark Volkmann >> Object Computing, Inc. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
