This would add a branch to the interface dispatch semantics, and while the branch is probably predictable, it would increase the size of every call site. Some benchmarking would be needed to demonstrate that the branch is less costly than a jump and immediate return sequence.
The correct answer is as Ian suggested earlier, a devirtualisation pass. I don't know anyone who is working on this. On Saturday, 2 December 2017 07:25:42 UTC+11, Ugorji Nwoke wrote: > > Yes. Fundamentally, I'm asking if step #2 in your calling sequence can be > optimized. > > 1. load a function pointer from the itab > 2. call the function pointer. *However, if the function pointer to is > empty, just do a NOP here and skip the function-call-dance. This should be > possible as the i-tab is created dynamically on first reference, which > means that it can know if the function is empty and put NOP indicator in > the i-tab instead of the function pointer. *That's the optimization I'm > asking about. > > On Friday, December 1, 2017 at 2:22:24 PM UTC-5, Ian Lance Taylor wrote: >> >> On Fri, Dec 1, 2017 at 10:42 AM, Ugorji Nwoke <ugo...@gmail.com> wrote: >> > >> > This is not so much about de-virtualization. It's about not making a >> call to >> > an empty function i.e. I expect that interface calls come down to >> > 1. dereference the pointer to the i-tab, >> > 2. jump to the appropriate function in the i-tab, >> > 3. call that function. >> >> That does not seem to me to be an accurate description of the current >> implementation. Calling a method of an interface is >> 1. load a function pointer from the itab >> 2. call the function pointer >> >> >> > If that function is a no-op, is the runtime smart enough to skip that >> > function call completely (e.g. replacing the entry in the i-tab with a >> NOP)? >> >> The itab does not contain code, it just holds function pointers. >> >> Ian >> > -- 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.
