llvm dev - Jun 2013 - [LLVMdev] Building a stable bitcode format for PNaCl - based on LLVM IR

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.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130618/56c04fdd/attachment.html>

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)

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130618/5577b0ea/attachment.html>

On Tue, Jun 18, 2013 at 3:08 PM, 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)
>
I just think it's a more useful discussion format for people knowledgeable
about LLVM. Dumping a huge LangRef-like reference manual on people is less
discussion-friendly :-) As I've mentioned, in reality (= code), the
approach is whitelisting so we shouldn't miss things that get added in
future LLVMs.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130618/81b1ce9b/attachment.html>

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>