This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [v3] libstdc++/44413 (for ext/vstring)


On 06/10/2010 05:03 PM, Doug Semler wrote:
> Yes, I'll check mainline when I get a chance and move the question
> about the potential miss to gcc list if it's there.
>   
Thanks. I learned a lot of time ago (from Gaby Dos Reis, for example)
that really since we are one and only project, GCC and its libraries, it
doesn't make sense to micro-optimize things at the library level as if
the compiler were immutable or outside our control: if you notice that
the compiler itself should be smart enough to perform a given
transformation, better pointing it out to the compiler people, because
in this way, among other advantages, similar user code will benefit too.
> (and actually the code that I would have suggested was (I had just put
> something together quickly so that I could just compile the function).
>
> difference_type __d = __n1 - __n2;
>  if (__d > __gnu_cxx::__numeric_traits<int>::__max)
>    __d =  __gnu_cxx::__numeric_traits<int>::__max;
>  else if (__d < __gnu_cxx::__numeric_traits<int>::__min)
>    __d =  __gnu_cxx::__numeric_traits<int>::__min;
>
>  return int(__d);
>   
... and indeed, this exactly *one* such case. I really expect the
optimizers to be able to figure out by themselves whether my form or
this one is the best.

... unless of course the compiler people tell us that is impossible
within the current technology, I don't think it may happen for such kind
of rearrangement of constants.

Paolo.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]