<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 08/26/2015 11:38 AM, Joseph
Tremoulet wrote:<br>
</div>
<blockquote
cite="mid:BY2PR0301MB0744F1A439982B366AA614D6CA600@BY2PR0301MB0744.namprd03.prod.outlook.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<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:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{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]-->
<div class="WordSection1">
<p class="MsoNormal">Hi,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Now that we have the token type
(<a class="moz-txt-link-freetext" href="http://reviews.llvm.org/rL245029">http://reviews.llvm.org/rL245029</a>), I need an operation that
will "extract" a non-token value from a token. I know people
have several use cases in mind for tokens, so I wanted to
solicit feedback on how general the solution should be (so
I've cc'ed the people from the review of the token change).
I'm also interested in getting consensus so that as
"extraction"s get added for each use case they have similar
look-and-feel.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">My particular need here is very narrow: I
need the 'catchpad' operation to define a value which is a
pointer to the on-heap exception object it catches (which my
target's personality routine will supply to the handler
code). Since the 'catchpad' operation is defined as producing
a token, in order to get at the exception pointer I need some
operation that can take that token as input and produce the
exception pointer as output.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Going fully general, I could imagine having
an operator with a name like 'tokenextract' that is
parameterized by the type it produces and accepts one argument
of type token plus zero or more arguments of arbitrary type
which indicate what is being extracted. If we're ever going
to want to support orthogonal kinds of extractions operating
on the same token value, I think that approach would break
down because it doesn't give a good way to specify which kind
of extraction is being performed. On the other hand, I think
it's entirely plausible that each token-producing operator
will only ever have a fixed set of extractions that make sense
for it, so this could be a workable solution under the
assumption that the way to interpret '%x = tokenextract %tok,
ty1 %arg1, ty2 %arg2' (for the sake of e.g. lowering out some
construct that is represented using token linkage) is to first
look at the operator defining %tok, and then interpret the
selector args in the context of that operation. This in turn
implies that each token-producing operator's definition (in
the Lang Ref) should spell out what can be extracted from it
and what its convention for selector args is. To my mind,
that's a bit too convoluted, and the informal description of
an operator's selector arg convention really seems like
something that one ought to be able to specify as typing
rules.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So I find myself arguing against a fully
general solution here. I think instead it makes sense for
each kind of extraction to specify an intrinsic that
represents it, with the argument/return types specified in the
usual way as the signature of the intrinsic. And on a
case-by-case basis any intrinsic could be replaced with an
instruction, following the same process that any other
operation follows as it finds its way into the IR.</p>
</div>
</blockquote>
After reading your description, I find myself with no strong opinion
either direction. Your discussion of the pros and cons of each
approach covers the topic well. I'd be perfectly willing to go
either direction due to the lack of a compelling argument in one
direction. I'd probably lean towards the generic version myself,
but I'm happy to defer to the people actual working on using the
mechanism at the moment.<br>
<blockquote
cite="mid:BY2PR0301MB0744F1A439982B366AA614D6CA600@BY2PR0301MB0744.namprd03.prod.outlook.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Ironically, the intrinsic approach that I'm
advocating is awkward for my actual use case of extracting an
exception pointer from a catchpad -- the argument and return
types should really be dictated by the personality routine,
and so can vary from function to function, but intrinsics only
support a limited form of overloading. But I think it would
be ok to start with an intrinsic (called
@llvm.eh.get_pad_param or something) that can be overloaded to
return anyptr (or maybe anyptr + anyint) and not worry about
more overloading until/unless we have more use cases.</p>
</div>
</blockquote>
Seems reasonable to me.<br>
<br>
We could also go with a generic mechanism based on a variadic
intrinsic if we wanted. We have all of the building blocks for this
between gc.result and gc.statepoint. If we combined a variadic
argument list with anyany result, we'd get an intrinsic with close
to the semantics of the instruction you were considering. We could
potentially use this to prototype both approaches and see which one
appears less ugly. <br>
<blockquote
cite="mid:BY2PR0301MB0744F1A439982B366AA614D6CA600@BY2PR0301MB0744.namprd03.prod.outlook.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thoughts?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks<o:p></o:p></p>
<p class="MsoNormal">-Joseph<o:p></o:p></p>
</div>
</blockquote>
<br>
</body>
</html>