<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 18 June 2013 15:08, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Tue, Jun 18, 2013 at 2:06 PM, Eli Bendersky <span dir="ltr"><<a href="mailto:eliben@google.com" target="_blank">eliben@google.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>On Tue, Jun 18, 2013 at 12:03 PM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Instead of a blacklist, why not a whitelist? Given the size of LangRef, you're bound to leave something out of your blacklist that needs to be there (also, future additions to LLVM IR will need to be added to the blacklist; are you sure you can catch *all* of them?). A whitelist seems much less prone to breakage or unexpected behavior.<span><font color="#888888"><div>



<div></div></div></font></span></div></blockquote><div><br></div></div><div>Hi Sean,</div><div><br></div><div>Which blacklist are you referring to? In all places where we specifically allow or disallow certain constructs (such as specific instructions, intrinsics, linkage modes and so on) we use a whitelisting strategy.</div>

<span><font color="#888888">
<div></div></font></span></div></div></div></blockquote><div><br></div></div></div><div>What I'm saying is that the approach to defining the format seems to be basically "the format is LLVM IR, except ...". The "except ..." is effectively a blacklist. You are starting with LLVM IR and then removing (i.e. blacklisting certain aspects)<br>
</div></div></div></div></blockquote><div><br></div><div>Well, PNaCl is defining a subset of LLVM IR.  Language subsets can be defined by whitelisting or blacklisting features.  Defining a subset of a language doesn't mean we're inherently doing blacklisting in PNaCl.</div>
<div><br></div><div>We are deferring to LLVM's definition of the language semantics for the features that PNaCl whitelists, and I think that's what you're referring to.  For example, we currently don't define what "phi" instructions mean; we rely on LLVM's definition.  If this became a problem, we could write down our own definition to make PNaCl's language better defined.  For example, we could specify whether a phi node requires 1 or 2 entries for a basic block B if there are 2 incoming edges from B.  I think the LLVM Language Reference currently does not specify this.<br>
<br></div>Cheers,<br>Mark<br><br></div></div></div>