<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:x="urn:schemas-microsoft-com:office:excel" 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-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;}
--></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">If this proves useful, I could amend my in-flight paper ( <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1105r0.html#rtti">
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>
<p class="MsoNormal"><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> cfe-dev <cfe-dev-bounces@lists.llvm.org> <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> kristina@nym.hush.com<br>
<b>Cc:</b> 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>
<p class="MsoNormal">As discussed on IRC, ISTM this would be better spelled as:<o:p></o:p></p>
<div>
<p class="MsoNormal"> typeid(<typename>).name();<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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"><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"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Mon, Sep 3, 2018 at 10:41 AM 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">
<p class="MsoNormal">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>
</body>
</html>