<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.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;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal-compose;
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;}
--></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">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"><o:p> </o:p></p>
<p class="MsoNormal">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>
<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> Richard Smith <richard@metafoo.co.uk> <br>
<b>Sent:</b> Tuesday, September 4, 2018 5:49 PM<br>
<b>To:</b> Ben Craig <ben.craig@ni.com><br>
<b>Cc:</b> James Y Knight <jyknight@google.com>; 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 Tue, 4 Sep 2018 at 15:02, Ben Craig via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">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-right:0in">
<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"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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"> <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>
<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">_______________________________________________<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>
</body>
</html>