public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Martin Liska <marxin@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc(refs/users/marxin/heads/sphinx-v2)] Update .rst files. Date: Fri, 25 Jun 2021 08:57:07 +0000 (GMT) [thread overview] Message-ID: <20210625085707.5464B385AC2C@sourceware.org> (raw) https://gcc.gnu.org/g:5f3b654ab00ef6d519e6fd27e2daebf05719e0ef commit 5f3b654ab00ef6d519e6fd27e2daebf05719e0ef Author: Martin Liska <mliska@suse.cz> Date: Fri Jun 25 10:56:27 2021 +0200 Update .rst files. Diff: --- .../link-time-optimization/design-overview.rst | 27 +++++++++++----------- .../standard-pattern-names-for-generation.rst | 11 ++++++++- 2 files changed, 23 insertions(+), 15 deletions(-) diff --git a/gcc/doc/gccint/link-time-optimization/design-overview.rst b/gcc/doc/gccint/link-time-optimization/design-overview.rst index e99342b77fe..b58c29d2f0b 100644 --- a/gcc/doc/gccint/link-time-optimization/design-overview.rst +++ b/gcc/doc/gccint/link-time-optimization/design-overview.rst @@ -13,11 +13,18 @@ bytecode representation of GIMPLE that is emitted in special sections of ``.o`` files. Currently, LTO support is enabled in most ELF-based systems, as well as darwin, cygwin and mingw systems. -Since GIMPLE bytecode is saved alongside final object code, object -files generated with LTO support are larger than regular object files. -This 'fat' object format makes it easy to integrate LTO into -existing build systems, as one can, for instance, produce archives of -the files. Additionally, one might be able to ship one set of fat +By default, object files generated with LTO support contain only GIMPLE +bytecode. Such objects are called 'slim', and they require that +tools like ``ar`` and ``nm`` understand symbol tables of LTO +sections. For most targets these tools have been extended to use the +plugin infrastructure, so GCC can support 'slim' objects consisting +of the intermediate code alone. + +GIMPLE bytecode could also be saved alongside final object code if +the :option:`-ffat-lto-objects` option is passed, or if no plugin support +is detected for ``ar`` and ``nm`` when GCC is configured. It makes +the object files generated with LTO support larger than regular object +files. This 'fat' object format allows to ship one set of fat objects which could be used both for development and the production of optimized builds. A, perhaps surprising, side effect of this feature is that any mistake in the toolchain leads to LTO information not @@ -26,14 +33,6 @@ This is both an advantage, as the system is more robust, and a disadvantage, as the user is not informed that the optimization has been disabled. -The current implementation only produces 'fat' objects, effectively -doubling compilation time and increasing file sizes up to 5x the -original size. This hides the problem that some tools, such as -``ar`` and ``nm``, need to understand symbol tables of LTO -sections. These tools were extended to use the plugin infrastructure, -and with these problems solved, GCC will also support 'slim' objects -consisting of the intermediate code alone. - At the highest level, LTO splits the compiler in two. The first half (the 'writer') produces a streaming representation of all the internal data structures needed to optimize and generate code. This @@ -121,4 +120,4 @@ minimize the number of references which cross partition boundaries. The main advantage of WHOPR is to allow the parallel execution of LTRANS stages, which are the most time-consuming part of the compilation process. Additionally, it avoids the need to load the -whole program into memory. \ No newline at end of file +whole program into memory. diff --git a/gcc/doc/gccint/machine-descriptions/standard-pattern-names-for-generation.rst b/gcc/doc/gccint/machine-descriptions/standard-pattern-names-for-generation.rst index e5fa88ad633..73f202935c1 100644 --- a/gcc/doc/gccint/machine-descriptions/standard-pattern-names-for-generation.rst +++ b/gcc/doc/gccint/machine-descriptions/standard-pattern-names-for-generation.rst @@ -1080,6 +1080,15 @@ vec_pack_sbool_trunc_m 1 and widen the resulting elements. Put the N/2 results of size 2\*S in the output vector (operand 0). + .. index:: vec_addsubm3 instruction pattern + +vec_addsubm3 + Alternating subtract, add with even lanes doing subtract and odd + lanes doing addition. Operands 1 and 2 and the outout operand are vectors + with mode :samp:`{m}`. + + These instructions are not allowed to ``FAIL``. + .. index:: mulhisi3 instruction pattern mulhisi3 @@ -3511,4 +3520,4 @@ clear_cache .. Each of the following nodes are wrapped in separate "@ifset INTERNALS" to work around memory limits for the default configuration in older tetex distributions. Known to not work: - tetex-1.0.7, known to work: tetex-2.0.2. \ No newline at end of file + tetex-1.0.7, known to work: tetex-2.0.2.
reply other threads:[~2021-06-25 8:57 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210625085707.5464B385AC2C@sourceware.org \ --to=marxin@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).