<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 1/2/20 10:40 AM, Keane, Erich via cfe-dev wrote:<br>
</div>
<blockquote type="cite" cite="mid:D0DD9254EE9DB04FA7C8606D0828DA6AD6BDD5A7@fmsmsx116.amr.corp.intel.com">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">While I definitely want us to try to document our implimits, I WILL say that we want to make sure we’re not publishing inaccurate numbers. Some of the limits are much harder than just testing. For example, template depth CAN be limited
by -ftemplate-depth, however we end up running out of stack space or memory with some fairly simple templates that way even before 1024.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If we publish these, I’d be wary that it would become expected that we could do template depth of 1024 (rather than that being a theoretical limit).</p>
</div>
</blockquote>
<p><br>
</p>
<p>I agree with this, but I also feel like this is not a huge problem in practice. Everything that the compiler does is subject to the availability of resources (and other permissions/capabilities). These limits being discussed impose additional restrictions,
and so limit the capabilities of the compiler even if resources are available, and so long as we provide the general disclaimer, I think that we can proceed without considering resource constraints specifically.</p>
<p>As far as rationale documentation goes, however, it would certainly make sense to note which limits are "practically unlimited", in the sense that you're likely to run out of resources far before you hit that particular threshold.<br>
</p>
<p> -Hal<br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:D0DD9254EE9DB04FA7C8606D0828DA6AD6BDD5A7@fmsmsx116.amr.corp.intel.com">
<div class="WordSection1">
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">One other concern I have is a more specific one, BitFieldBits, which limits the size by setting a bitfield size itself (in CGRecordLayout). The current size is chosen in a way that seems to intentionally make a size of CGBitFieldInfo not
have padding. Any time we create one of these we need to make sure that we document the reason for the size, so that we have an understanding of why it was set that size.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Finally, I believe we should diagnose on all of the implimits that we come across as well. BitFieldBits is very important one to do semantic analysis diagnosis on, particularly if we’re going to document it.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> cfe-dev <a class="moz-txt-link-rfc2396E" href="mailto:cfe-dev-bounces@lists.llvm.org">
<cfe-dev-bounces@lists.llvm.org></a> <b>On Behalf Of </b>via cfe-dev<br>
<b>Sent:</b> Thursday, January 2, 2020 8:29 AM<br>
<b>To:</b> Mark de Wever <a class="moz-txt-link-rfc2396E" href="mailto:koraq@xs4all.nl">
<koraq@xs4all.nl></a><br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:aaron.ballman@gmail.com">
aaron.ballman@gmail.com</a>; <a class="moz-txt-link-abbreviated" href="mailto:richard@metafoo.co.uk">
richard@metafoo.co.uk</a>; cfe-dev <a class="moz-txt-link-rfc2396E" href="mailto:cfe-dev@lists.llvm.org">
<cfe-dev@lists.llvm.org></a><br>
<b>Subject:</b> Re: [cfe-dev] [RFC] Handling implementation limits<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">This is a very good idea as documenting these limits will be very helpful for anyone who is using Clang within a MISRA coding environment, where these limits need to be known when configuring static analysis tools.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif">Chris Tapp, MISRA C++ Chairman<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On 1 Jan 2020, at 16:16, Mark de Wever via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" moz-do-not-send="true">cfe-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">This RFC asks the community for its interest in centralizing Clang's<br>
implementation limits and how you feel about the proposed approach.<br>
<br>
Abstract<br>
========<br>
<br>
At the moment the implementation limits of the Clang compiler are hidden<br>
in magic numbers in the code. These numbers sometimes differ between the<br>
frontend and the backend. They are not always properly guarded by compiler<br>
warnings, instead they trigger assertion failures.<br>
<br>
This proposal suggests a TableGen based solution to better maintain these<br>
limits. This solution will be able to generate a header and documentation<br>
of these limits. The latter is required by the C++ standard [implimits].<br>
<br>
<br>
The problem<br>
===========<br>
<br>
The proposal tries to solve 2 issues:<br>
* Implementation limits are not always clear and duplicated in the source.<br>
* Document C++ Implementation quantities is required by the C++ standard<br>
[implimits].<br>
<br>
<br>
Unclear limits<br>
--------------<br>
<br>
The compiler has several limitations often 'hidden' as the width of a<br>
bit-field in a structure. This makes it hard to find these limits. Not<br>
only for our users but also for developers. While looking at a proper<br>
limit for the maximum width of a bit-field in the frontend I discovered<br>
it didn't matter what the frontend picked, the backend already had a<br>
limit [D71142]. To fix this issue the frontend and backend should have<br>
the same limit. To avoid duplicating the value it should be in a header<br>
available to the frontend and backend.<br>
<br>
Since the values are often stored in a bit-field there is no standard way<br>
to get the maximum value. This means the limit needs a small helper<br>
function to get the value, for example [D63975] uses<br>
`getMaxFunctionScopeDepth()`.<br>
<br>
<br>
Standard conformance<br>
--------------------<br>
<br>
This is rather simple the C++ standard Annex B states:<br>
Because computers are finite, C++ implementations are inevitably<br>
limited in the size of the programs they can successfully process.<br>
Every implementation shall document those limitations where known.<br>
<br>
Currently this documentation is not available.<br>
<br>
<br>
The proposed solution<br>
=====================<br>
<br>
In order to solve this issue I created a proof-of-concept solution<br>
[D72053]. It contains a new file<br>
clang/include/clang/Basic/ImplementationQuantities.td with two TableGen<br>
generators which create:<br>
* An inc file with a set of constants containing the limits. This file<br>
$BUILD_DIR/tools/clang/include/clang/Basic/ImplementationQuantities.inc<br>
is included in the header<br>
clang/include/clang/Basic/ImplementationQuantities.h.<br>
* The document clang/docs/ImplementationQuantities.rst<br>
This document documents the limits of Clang. These limits include, but<br>
are not limited to the quantities in [implimits].<br>
<br>
The quantity limit has the following possible types:<br>
* The quantity is limited by the number of bits in a bit-field. TableGen<br>
generates two constants:<br>
* FieldNameBits, the number of bits in the bit-field.<br>
* MaxFieldName, the maximum value of the bit-field. (This assumes all<br>
bit-fields can be stored in an unsigned.)<br>
* The quantity is limited by a value. TableGen generates one constant:<br>
* MaxFieldName, the maximum value of the field.<br>
* The quantity's limit is determined by a compiler flag. TableGen<br>
generates one constant:<br>
* FieldNameDefault, the default value of the compiler flag.<br>
* The quantity's limit cannot be expressed in a number. For example it<br>
depends on the stack size or available memory of the system. In this<br>
case TableGen generates no constant, only documentation.<br>
<br>
For all types documentation is generated. The documentation shows the<br>
description of the limit and the limit implemented in Clang. If the<br>
recommended value is not 0 it is a value described in the C++ Standard. In<br>
this case the recommended value is shown in the documentation.<br>
<br>
<br>
Questions<br>
=========<br>
<br>
* If this proposal is accepted how to we make sure the document is updated<br>
before releasing a new version of clang?<br>
* The compiler flag limits are also documented in the UserManual. This means<br>
these limits are still duplicated. Do we want to let the UserManual also be<br>
generated and use the values here or just keep the duplication?<br>
<br>
<br>
Bikeshed<br>
========<br>
<br>
I picked IQ for the namespace of the quantities since it's short and not<br>
often used in the codebase so it's easy greppable.<br>
<br>
<br>
[implimits] <a href="http://eel.is/c++draft/implimits" moz-do-not-send="true">http://eel.is/c++draft/implimits</a><br>
[D63975] <a href="https://reviews.llvm.org/D63975" moz-do-not-send="true">https://reviews.llvm.org/D63975</a><br>
[D71142] <a href="https://reviews.llvm.org/D71142" moz-do-not-send="true">https://reviews.llvm.org/D71142</a><br>
[D72053] <a href="https://reviews.llvm.org/D72053" moz-do-not-send="true">https://reviews.llvm.org/D72053</a><br>
<br>
<br>
Kind regards,<br>
Mark de Wever<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" moz-do-not-send="true">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>