[LLVMdev] Building a stable bitcode format for PNaCl - based on LLVM IR

[Mark Seaborn]

On 18 June 2013 15:08, Sean Silva <silvas at purdue.edu> wrote:

> On Tue, Jun 18, 2013 at 2:06 PM, Eli Bendersky <eliben at google.com> wrote:
>
>> On Tue, Jun 18, 2013 at 12:03 PM, Sean Silva <silvas at purdue.edu> wrote:
>>
>>> 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.
>>>
>>
>> Hi Sean,
>>
>> 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.
>>
>
> 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)
>

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.

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.

Cheers,
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130618/64d30ac2/attachment.html>