diff options
| author | alk3pInjection <webmaster@raspii.tech> | 2024-02-04 16:16:35 +0800 |
|---|---|---|
| committer | alk3pInjection <webmaster@raspii.tech> | 2024-02-04 16:16:35 +0800 |
| commit | abdaadbcae30fe0c9a66c7516798279fdfd97750 (patch) | |
| tree | 00a54a6e25601e43876d03c1a4a12a749d4a914c /share/doc/gccint/Guidelines-for-using-poly_005fint.html | |
https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads
Change-Id: I7303388733328cd98ab9aa3c30236db67f2e9e9c
Diffstat (limited to 'share/doc/gccint/Guidelines-for-using-poly_005fint.html')
| -rw-r--r-- | share/doc/gccint/Guidelines-for-using-poly_005fint.html | 209 |
1 files changed, 209 insertions, 0 deletions
diff --git a/share/doc/gccint/Guidelines-for-using-poly_005fint.html b/share/doc/gccint/Guidelines-for-using-poly_005fint.html new file mode 100644 index 0000000..0a53a7a --- /dev/null +++ b/share/doc/gccint/Guidelines-for-using-poly_005fint.html @@ -0,0 +1,209 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> +<html> +<!-- Copyright (C) 1988-2023 Free Software Foundation, Inc. + +Permission is granted to copy, distribute and/or modify this document +under the terms of the GNU Free Documentation License, Version 1.3 or +any later version published by the Free Software Foundation; with the +Invariant Sections being "Funding Free Software", the Front-Cover +Texts being (a) (see below), and with the Back-Cover Texts being (b) +(see below). A copy of the license is included in the section entitled +"GNU Free Documentation License". + +(a) The FSF's Front-Cover Text is: + +A GNU Manual + +(b) The FSF's Back-Cover Text is: + +You have freedom to copy and modify this GNU Manual, like GNU + software. Copies published by the Free Software Foundation raise + funds for GNU development. --> +<!-- Created by GNU Texinfo 5.1, http://www.gnu.org/software/texinfo/ --> +<head> +<title>GNU Compiler Collection (GCC) Internals: Guidelines for using poly_int</title> + +<meta name="description" content="GNU Compiler Collection (GCC) Internals: Guidelines for using poly_int"> +<meta name="keywords" content="GNU Compiler Collection (GCC) Internals: Guidelines for using poly_int"> +<meta name="resource-type" content="document"> +<meta name="distribution" content="global"> +<meta name="Generator" content="makeinfo"> +<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> +<link href="index.html#Top" rel="start" title="Top"> +<link href="Option-Index.html#Option-Index" rel="index" title="Option Index"> +<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents"> +<link href="poly_005fint.html#poly_005fint" rel="up" title="poly_int"> +<link href="GENERIC.html#GENERIC" rel="next" title="GENERIC"> +<link href="Miscellaneous-poly_005fint-routines.html#Miscellaneous-poly_005fint-routines" rel="previous" title="Miscellaneous poly_int routines"> +<style type="text/css"> +<!-- +a.summary-letter {text-decoration: none} +blockquote.smallquotation {font-size: smaller} +div.display {margin-left: 3.2em} +div.example {margin-left: 3.2em} +div.indentedblock {margin-left: 3.2em} +div.lisp {margin-left: 3.2em} +div.smalldisplay {margin-left: 3.2em} +div.smallexample {margin-left: 3.2em} +div.smallindentedblock {margin-left: 3.2em; font-size: smaller} +div.smalllisp {margin-left: 3.2em} +kbd {font-style:oblique} +pre.display {font-family: inherit} +pre.format {font-family: inherit} +pre.menu-comment {font-family: serif} +pre.menu-preformatted {font-family: serif} +pre.smalldisplay {font-family: inherit; font-size: smaller} +pre.smallexample {font-size: smaller} +pre.smallformat {font-family: inherit; font-size: smaller} +pre.smalllisp {font-size: smaller} +span.nocodebreak {white-space:nowrap} +span.nolinebreak {white-space:nowrap} +span.roman {font-family:serif; font-weight:normal} +span.sansserif {font-family:sans-serif; font-weight:normal} +ul.no-bullet {list-style: none} +--> +</style> + + +</head> + +<body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000"> +<a name="Guidelines-for-using-poly_005fint"></a> +<div class="header"> +<p> +Previous: <a href="Miscellaneous-poly_005fint-routines.html#Miscellaneous-poly_005fint-routines" accesskey="p" rel="previous">Miscellaneous <code>poly_int</code> routines</a>, Up: <a href="poly_005fint.html#poly_005fint" accesskey="u" rel="up">poly_int</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p> +</div> +<hr> +<a name="Guidelines-for-using-poly_005fint-1"></a> +<h3 class="section">10.9 Guidelines for using <code>poly_int</code></h3> + +<p>One of the main design goals of <code>poly_int</code> was to make it easy +to write target-independent code that handles variable-sized registers +even when the current target has fixed-sized registers. There are two +aspects to this: +</p> +<ul> +<li> The set of <code>poly_int</code> operations should be complete enough that +the question in most cases becomes “Can we do this operation on these +particular <code>poly_int</code> values? If not, bail out” rather than +“Are these <code>poly_int</code> values constant? If so, do the operation, +otherwise bail out”. + +</li><li> If target-independent code compiles and runs correctly on a target +with one value of <code>NUM_POLY_INT_COEFFS</code>, and if the code does not +use asserting functions like <code>to_constant</code>, it is reasonable to +assume that the code also works on targets with other values of +<code>NUM_POLY_INT_COEFFS</code>. There is no need to check this during +everyday development. +</li></ul> + +<p>So the general principle is: if target-independent code is dealing +with a <code>poly_int</code> value, it is better to operate on it as a +<code>poly_int</code> if at all possible, choosing conservatively-correct +behavior if a particular operation fails. For example, the following +code handles an index <code>pos</code> into a sequence of vectors that each +have <code>nunits</code> elements: +</p> +<div class="smallexample"> +<pre class="smallexample">/* Calculate which vector contains the result, and which lane of + that vector we need. */ +if (!can_div_trunc_p (pos, nunits, &vec_entry, &vec_index)) + { + if (dump_enabled_p ()) + dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location, + "Cannot determine which vector holds the" + " final result.\n"); + return false; + } +</pre></div> + +<p>However, there are some contexts in which operating on a +<code>poly_int</code> is not possible or does not make sense. One example +is when handling static initializers, since no current target supports +the concept of a variable-length static initializer. In these +situations, a reasonable fallback is: +</p> +<div class="smallexample"> +<pre class="smallexample">if (<var>poly_value</var>.is_constant (&<var>const_value</var>)) + { + … + /* Operate on <var>const_value</var>. */ + … + } +else + { + … + /* Conservatively correct fallback. */ + … + } +</pre></div> + +<p><code>poly_int</code> also provides some asserting functions like +<code>to_constant</code>. Please only use these functions if there is a +good theoretical reason to believe that the assertion cannot fire. +For example, if some work is divided into an analysis phase and an +implementation phase, the analysis phase might reject inputs that are +not <code>is_constant</code>, in which case the implementation phase can +reasonably use <code>to_constant</code> on the remaining inputs. The assertions +should not be used to discover whether a condition ever occurs “in the +field”; in other words, they should not be used to restrict code to +constants at first, with the intention of only implementing a +<code>poly_int</code> version if a user hits the assertion. +</p> +<p>If a particular asserting function like <code>to_constant</code> is needed +more than once for the same reason, it is probably worth adding a +helper function or macro for that situation, so that the justification +only needs to be given once. For example: +</p> +<div class="smallexample"> +<pre class="smallexample">/* Return the size of an element in a vector of size SIZE, given that + the vector has NELTS elements. The return value is in the same units + as SIZE (either bits or bytes). + + to_constant () is safe in this situation because vector elements are + always constant-sized scalars. */ +#define vector_element_size(SIZE, NELTS) \ + (exact_div (SIZE, NELTS).to_constant ()) +</pre></div> + +<p>Target-specific code in <samp>config/<var>cpu</var></samp> only needs to handle +non-constant <code>poly_int</code>s if <code>NUM_POLY_INT_COEFFS</code> is greater +than one. For other targets, <code>poly_int</code> degenerates to a compile-time +constant and is often interchangable with a normal scalar integer. +There are two main exceptions: +</p> +<ul> +<li> Sometimes an explicit cast to an integer type might be needed, such as to +resolve ambiguities in a <code>?:</code> expression, or when passing values +through <code>...</code> to things like print functions. + +</li><li> Target macros are included in target-independent code and so do not +have access to the implicit conversion to a scalar integer. +If this becomes a problem for a particular target macro, the +possible solutions, in order of preference, are: + +<ul> +<li> Convert the target macro to a target hook (for all targets). + +</li><li> Put the target’s implementation of the target macro in its +<samp><var>cpu</var>.c</samp> file and call it from the target macro in the +<samp><var>cpu</var>.h</samp> file. + +</li><li> Add <code>to_constant ()</code> calls where necessary. The previous option +is preferable because it will help with any future conversion of the +macro to a hook. +</li></ul> +</li></ul> + + + +<hr> +<div class="header"> +<p> +Previous: <a href="Miscellaneous-poly_005fint-routines.html#Miscellaneous-poly_005fint-routines" accesskey="p" rel="previous">Miscellaneous <code>poly_int</code> routines</a>, Up: <a href="poly_005fint.html#poly_005fint" accesskey="u" rel="up">poly_int</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p> +</div> + + + +</body> +</html> |