[PATCH] Avoid excessive function type casts with splay-trees part 2

Richard Biener rguenther@suse.de
Fri Jun 15 07:07:00 GMT 2018


On Thu, 14 Jun 2018, Bernd Edlinger wrote:

> On 06/14/18 15:43, Richard Biener wrote:
> > On Fri, 8 Jun 2018, Bernd Edlinger wrote:
> > 
> >> Hi!
> >>
> >>
> >> This patch converts the splay-tree internals into a template, and makes
> >> the typed_splay_tree template really type-safe.  Previously everything
> >> would break apart if KEY_TYPE or VALUE_TYPE would not be pointer types.
> >> This limitation is now removed.
> >>
> >> I took the freedom to add a remove function which is only for
> >> completeness and test coverage, but not (yet) used in a productive way.
> >>
> >>
> >> Bootstrapped and reg-tested on x86_64-linux-gnu.
> >> Is it OK for trunk?
> > 
> > It looks OK to me but I wonder if we can avoid some of the code
> > duplication due to template instantiation by deriving from a non-templated
> > base class somehow?  The cc1* binaries keep growing with more and
> > more template use :/
> > 
> 
> 
> No problem.  The first version used an approach where splay-tree
> exposes an extended interface with a context pointer.
> 
> See: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00178.html
> 
> But it has also a limitation when the value or type is a class, it will
> not be possible to cast to uintptr_t, it will fail to compile, which is
> still an improvement since the current version just casts incompatible
> function pointers, and since I had to silence the -Wcast-function-type
> the warning would not help either.
> 
> 
> If you like the original patch better than the template, I can cleanup
> the original patch as an alternative?

No, I like the template more but wondered if we can somehow outline
some of the main worker code?

Thanks,
Richard.



More information about the Gcc-patches mailing list