Displaying 4 results from an estimated 4 matches for "ugin".
Did you mean:
gin
2017 Jan 16
2
Your help needed: List of LLVM Open Projects 2017
...ion” is needed, and what
>>> makes it
>>> > easier for MonolithicLTO compared to ThinLTO?
>>> >
>>> > Or maybe that layout code should be inside LLVM; maybe part of the
>>> general
>>> > LTO interface? It looks like the current gcc plugin calls back into
>>> gcc for
>>> > the actual layout algorithm itself (function call
>>> > find_pettis_hansen_function_layout) rather than the reordering logic
>>> living
>>> > in the linker:
>>> > https://android.googlesource.com/too...
2017 Jan 17
4
Your help needed: List of LLVM Open Projects 2017
...ed build would still have quite a bit
of useful information.
-- Sean Silva
On Mon, Jan 16, 2017 at 4:33 PM, Xinliang David Li <xinliangli at gmail.com>
wrote:
> Google GCC records profile data (dynamic callgraph) in a special named
> section in ELF object file to be consumed by the plugin. Those sections
> will be discarded later by the linker.
>
> There are pros and cons of using xray for layout purpose. The call trace
> from xray is certainly more powerful for layout purpose, but it adds
> addtional complexity to the optimized build process. You would need to
>...
2018 Apr 05
2
[nbdkit PATCH] tests: Skip guestfs tests on CentOS 6
CentOS 6 has libguestfs-devel 1.20.11, which predates the support
in guestfs_add_drive_opts() for requesting an nbd drive instead
of a local file. The guestfs plugin can still be built, so no
configure changes are needed; but skip the tests that fail to
compile so that 'make check' can at least complete.
Signed-off-by: Eric Blake <eblake@redhat.com>
---
Even with this patch, there are still failures:
/home/dummy/nbdkit/src/nbdkit -U /tmp/nbdki...
2017 Jan 16
2
Your help needed: List of LLVM Open Projects 2017
...> I’m not sure what kind of “profile information” is needed, and what
> makes it
> > easier for MonolithicLTO compared to ThinLTO?
> >
> > Or maybe that layout code should be inside LLVM; maybe part of the
> general
> > LTO interface? It looks like the current gcc plugin calls back into gcc
> for
> > the actual layout algorithm itself (function call
> > find_pettis_hansen_function_layout) rather than the reordering logic
> living
> > in the linker:
> > https://android.googlesource.com/toolchain/gcc/+/
> 3f73d6ef90458b45bbbb33ef4c2b1...