<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@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.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
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.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:114180297;
mso-list-type:hybrid;
mso-list-template-ids:-231992326 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1
{mso-list-id:1474716191;
mso-list-type:hybrid;
mso-list-template-ids:-1256953922 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">What happens if you…<o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo1">typeid(ClassWithExternalVtable) from a -fno-rtti TU, and the vtable is in a -frtti TU?
<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo1">typeid in the -frtti, vtable in the -fno-rtti?<o:p></o:p></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Wild guesses…<o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo2">will cause an extra, weak linkage type_info to be created, but the linker or loader will use the one from the -frtti TU. Object file size suffers a little bit, but people are generally
happy.<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo2">I’m expecting an error at link or load time here, because the -frtti TU is expecting someone else to provide the type_info, but no one does.<o:p></o:p></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> James Y Knight <jyknight@google.com> <br>
<b>Sent:</b> Thursday, September 6, 2018 10:49 AM<br>
<b>To:</b> Ben Craig <ben.craig@ni.com><br>
<b>Cc:</b> Richard Smith <richard@metafoo.co.uk>; kristina@nym.hush.com; Clang Dev <cfe-dev@lists.llvm.org><br>
<b>Subject:</b> Re: [cfe-dev] [Proposal]: Fast non-portable extension to retrieve a type name from a pointer as a GV: __builtin_type_name(T* Ptr, [int Style])<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">On Wed, Sep 5, 2018 at 10:32 PM Ben Craig <<a href="mailto:ben.craig@ni.com">ben.craig@ni.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Which TU(s) will the type_info object go in, and what will the linkage of those objects be? If you call typeid(SomeClass), and all of SomeClass’s functions are out-of-lined in
another TU, will you generate a type_info object of weak_linkage in the current TU? Or will you expect the TU that has SomeClass’s functions in it to define the type_info object?<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I think if you want things to work, then you will need to generate a weak linkage type_info in each TU that calls typeid(SomeClass). I’m not sure if that’s ok or not though.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Yes, the last. It is what we do already -- only in special cases can we assume that there is typeinfo available externally (certain standard types, and when RTTI is enabled, types with an externally available vtable). In other cases, the
typeinfo is already emitted where required, with weak linkage.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:</b> Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>>
<br>
<b>Sent:</b> Tuesday, September 4, 2018 5:49 PM<br>
<b>To:</b> Ben Craig <<a href="mailto:ben.craig@ni.com" target="_blank">ben.craig@ni.com</a>><br>
<b>Cc:</b> James Y Knight <<a href="mailto:jyknight@google.com" target="_blank">jyknight@google.com</a>>;
<a href="mailto:kristina@nym.hush.com" target="_blank">kristina@nym.hush.com</a>; Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
<b>Subject:</b> Re: [cfe-dev] [Proposal]: Fast non-portable extension to retrieve a type name from a pointer as a GV: __builtin_type_name(T* Ptr, [int Style])<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Tue, 4 Sep 2018 at 15:02, Ben Craig via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">If this proves useful, I could amend my in-flight paper (
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.open-2Dstd.org_jtc1_sc22_wg21_docs_papers_2018_p1105r0.html-23rtti&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=7aFHQSaTijYTIv4QldkgDVFOtHraMIeWJ9BI91rRi2c&s=DIlVM7DkikKHU3dBzN5SBhcNaQ5wA2a0k8xuUbDoasE&e=" target="_blank">
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1105r0.html#rtti</a> ) to allow for typeid(type) in freestanding, while still allowing typeid(variable) to be ill formed. I would need to carefully evaluate how much of <typeinfo> and <typeindex> would
make sense.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">If you go down this path, it would make more sense to only disallow the dynamic form of typeid(expr) (that is, when the operand is a glvalue of polymorphic class type). There's
also implementation experience of that: that's what MSVC's /GR- flag does.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:</b> cfe-dev <<a href="mailto:cfe-dev-bounces@lists.llvm.org" target="_blank">cfe-dev-bounces@lists.llvm.org</a>>
<b>On Behalf Of </b>James Y Knight via cfe-dev<br>
<b>Sent:</b> Tuesday, September 4, 2018 4:42 PM<br>
<b>To:</b> <a href="mailto:kristina@nym.hush.com" target="_blank">kristina@nym.hush.com</a><br>
<b>Cc:</b> Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
<b>Subject:</b> Re: [cfe-dev] [Proposal]: Fast non-portable extension to retrieve a type name from a pointer as a GV: __builtin_type_name(T* Ptr, [int Style])<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">As discussed on IRC, ISTM this would be better spelled as:<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> typeid(<typename>).name();<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The issue with that at the moment is that typeid() is an error if you build with -fno-rtti. However, there appears to be no reason why we cannot support `typeid(<typename>)` even
with -fno-rtti. Unlike `typeid(<variable>)`, it requires no extra data to be emitted, since there's no possibility that dynamic dispatch is required. Therefore, similarly to how exception support still functions with -fno-rtti by emitting the explicitly required
typeinfo data on demand, so too can typeid(<typename>).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I note also that when .name() is the only value used, the remainder of the typeinfo data is already omitted from the output when compiling with optimizations.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
It looks like supporting this would be only be a few line change in clang, since all the underlying infrastructure is there already to support the EH with -fno-rtti use-case.<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Mon, Sep 3, 2018 at 10:41 AM via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The concept itself is pretty trivial, the builtin takes one or two arguments, one of which<br>
has to be a pointer to an arbitrary type, this makes it particularly useful with C++<br>
auto declarations or even printing the type by simply casting a null pointer to<br>
the type in question. It's qualifiers are retained for the sake of printing them<br>
depending on the requested style.<br>
<br>
Implementation<br>
^^^^^^^^^^^^^^<br>
<br>
const char* TypeName = __builtin_type_name(T* Ptr, [int Style])<br>
<br>
After validating either 1 or 2 argument form (ie. Pointed to type, and whether it's a
<br>
record declaration), SemaChecking will set the return type to TheCall->setType(<br>
Context.getPointerType(Context.CharTy.withConst())) leaving it for Clang's CodeGen<br>
to deal with.<br>
<br>
Second argument is used to control the output format in form of a bitmask<br>
passed down to PrintingPolicy (as I port this I will decouple the values so the <br>
builtin's behavior isn't dependent on further changes in PrintingPolicy. At <br>
which point the type is retrieved using `getAsString` and stored in the CGM <br>
with `GetAddrOfConstantCString` allowing coalescing of those strings later <br>
during linking. as it's cast to a Int8Ptr.<br>
<br>
This is all done in Clang without needing to add anything to the LLVM core.<br>
<br>
Things left to do before submitting for code review<br>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
* There is no test coverage, so I need to write up a test file, comprehensively<br>
testing cases I haven't considered before like Objective-C pointers, any<br>
pointer to a special Clang type that may behave unexpectedly, complex<br>
C++ templates (or simple ones, was my main use of it). Target is IR since<br>
Clang fully lowers it, so in theory it's platform agnostic providing there is<br>
enough space (the original use was for Embedded C++ with no RTTI.<br>
* While this is out of scope, a GUID buffer as a a style would provide a form<br>
type IDs in absence of RTTI or alternatively smaller types like u32 or u16<br>
(aimed at single module builds where they can remain unique, ie. embedded<br>
systems with a kernel using those to represent kernel object types).<br>
<br>
Rationale<br>
^^^^^^^^^<br>
It's clear that this functionality is desired outside of embedded domain,<br>
typically with hacks involving a lambda and __PRETTY_FUNCTION__, on case<br>
being in `lib/Support/TypeName.h` in LLVMSupport. Many non-portable hacks<br>
that depend on compiler versions exist. This doesn't aim to be portable,<br>
just to be compact, not have a runtime cost, and provide this information<br>
either for debugging or even for more practical reasons.<br>
<br>
I wanted to find out if there was interest in this kind of thing since<br>
I have developed a variety of different useful and not so useful extensions,<br>
originally for embedded use but I want to upstream them for general use,<br>
I want to know what the consensus is on 1) This particular extension<br>
2). Further extensions that were originally developed for embedded use<br>
but have turned out to be useful in a lot of contexts where you are willing<br>
to sacrifice portability (now with `__has_builtin` this is extremely easy to <br>
test for and fallback on something else).<br>
<br>
On the other hand it's a lot to do overall so I would prefer to get a consensus<br>
whether each feature (even this small one) is worth cleaning up and putting<br>
up for code review, since I understand that something like builtin bloat<br>
or non portability may be of concern. As for the formal name I'd like to call<br>
it extensions for Embedded C++ 2 gating it behind an opt-in flag such as<br>
`-fecxx2-extensions`.<br>
<br>
Other things involve limited reflection retrieving the bare minimum that's<br>
needed, a llvm::formatv style formatter accelerator, getting names of record<br>
scope at different levels with 0 being similar to the desired __CLASSNAME__ <br>
macro (at least by some).<br>
<br>
Looking forward to any feedback whether positive or negative.<br>
Thank you for your time.<br>
- Kristina<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Ddev&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=-sbbHSiNjZYv97P_NOvZquxu27yN18IZsUBeKIBtYN8&s=wg_6fnqbc-wF7U1ZrUAr6UnwHYQegzVRuQLTCJqn_YM&e=" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Ddev&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=7aFHQSaTijYTIv4QldkgDVFOtHraMIeWJ9BI91rRi2c&s=4lVMCfxPmZ3n-7uGW3BhNzswEi1LSw3n63eDKRDhFgs&e=" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>