This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Strengthen ICF hash
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, Andi Kleen <andi at firstfloor dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>, mliska at suse dot cz
- Date: Wed, 4 Mar 2015 22:18:34 +0100
- Subject: Re: Strengthen ICF hash
- Authentication-results: sourceware.org; auth=none
- References: <20150301214405 dot GB95914 at kam dot mff dot cuni dot cz> <87wq30tah7 dot fsf at tassilo dot jf dot intel dot com> <20150303072545 dot GA84757 at kam dot mff dot cuni dot cz> <20150304131959 dot GK823 at two dot firstfloor dot org> <CAFiYyc2TfH9hokuj__=02g_VnRdM5DEaN73BLM_Z-MNYqezDng at mail dot gmail dot com> <20150304202224 dot GC21291 at atrey dot karlin dot mff dot cuni dot cz> <52B80006-1032-4EF2-9465-F3A35053CA02 at gmail dot com>
> On March 4, 2015 9:22:24 PM CET, Jan Hubicka <hubicka@ucw.cz> wrote:
> >> On Wed, Mar 4, 2015 at 2:20 PM, Andi Kleen <andi@firstfloor.org>
> >wrote:
> >> > Hi Honza,
> >> >
> >> > Regarding modern hash functions, as far as I understand the trend
> >> > is to just stop doing anything fancy and just use the CRC
> >instructions
> >> > in modern CPUs
> >>
> >> I wonder if we can use intrinsics for CRC in place of the
> >> existing iterative_hash_hashval_t (and thus the 'mix' macro)?
> >> Similar to how we optimize libcpp? Seems like
> >>
> >> #define mix(a,b,c) \
> >> c = _mm_crc32_u32 (b, c)
> >>
> >> would do? And for iterative_hash_host_wide_int use _mm_crc32_u64?
> >> (libcpp seems to use GCC target builtins, not intrinsics though,
> >> see init_vectorized_lexer)
> >
> >That looks like a good idea. From tree/ICF sreaming we however needs
> >to get host independent at some point. Can we have resonable&compatible
> >generic implementation?
>
> I honestly don't see us ending up with a host independent LTO byte code. I know we kind of try, but did anybody try using bytecode produced by a cross on a native system?
Not in GCC-5. But in longer run I do expect people to be able to ship LTO .o
objects given major GCC version match. Other compilers including LLVM does
that, we should too. It has other benefits, too - like forcing us to design
things in clean and maintainable manner.
After early debug (hopefully landing in GCC 6) and with gimple/trees interface
cleanups, I think well defined IL stream may be next reachable goal though.
For optimization summaries I have alternative plan - those can stay subversion
specific. If you get mismatch for minor version, you can just recompute them
on WPA time. Assuming the LTO shipped libraries will be of controlled size, it
should not be too bad.
But yes, I do not think we need to significantly slow things down in current
implemetnation when this feature does not work. Just perhaps keep track of
changes that introduce host specific stuff and not introduce these when it is
easily avoidable.
Honza
>
> Richard.
>
> >Honza
>
>