llvm dev - Aug 2015 - [LLVMdev] [RFC] Developer Policy for LLVM C API

On Sun, Aug 16, 2015 at 9:49 PM deadal nix <deadalnix at gmail.com> wrote:
> 2015-08-16 21:47 GMT-07:00 Eric Christopher <echristo at gmail.com>:
>
>>
>>
>> On Sun, Aug 16, 2015 at 6:45 PM deadal nix via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Chiming in with http://reviews.llvm.org/D10725
>>>
>>> Being able to read and generate IR is at least some very basic
thing we
>>> can agree on is needed. Can we get some testing for it ? Personally
I don't
>>> really mind if this is going to be stable or not, but at least,
having some
>>> test coverage would allow to take whatever path that is going to be
taken
>>> willingly.
>>>
>>>
>> Right, and that's the problem. Expanding the C API to cover reading
and
>> generating IR in a stable way will lock the C++ API down in a way that
I'm
>> not comfortable with - I think it has already gone too far.
>>
>> -eric
>>
>
> That seems like a bare minimum.
>
> The C++ evolve from one version to another, what is preventing the C API
> to do the same ?
>
>
The promise of stability. We don't promise that the C++ API will stay
stable.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150817/03b052d0/attachment.html>

2015-08-16 21:51 GMT-07:00 Eric Christopher <echristo at gmail.com>:
>
>
> On Sun, Aug 16, 2015 at 9:49 PM deadal nix <deadalnix at gmail.com>
wrote:
>
>> 2015-08-16 21:47 GMT-07:00 Eric Christopher <echristo at
gmail.com>:
>>
>>>
>>>
>>> On Sun, Aug 16, 2015 at 6:45 PM deadal nix via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> Chiming in with http://reviews.llvm.org/D10725
>>>>
>>>> Being able to read and generate IR is at least some very basic
thing we
>>>> can agree on is needed. Can we get some testing for it ?
Personally I don't
>>>> really mind if this is going to be stable or not, but at least,
having some
>>>> test coverage would allow to take whatever path that is going
to be taken
>>>> willingly.
>>>>
>>>>
>>> Right, and that's the problem. Expanding the C API to cover
reading and
>>> generating IR in a stable way will lock the C++ API down in a way
that I'm
>>> not comfortable with - I think it has already gone too far.
>>>
>>> -eric
>>>
>>
>> That seems like a bare minimum.
>>
>> The C++ evolve from one version to another, what is preventing the C
API
>> to do the same ?
>>
>>
> The promise of stability. We don't promise that the C++ API will stay
> stable.
>
> -eric
>

Why was that promise be made in the first place ? Has it been made in the
first place ?

Also, whether, the C API is stable or change between version, being able to
read and write IR from it seems like a bare minimum and having test for
this as well.

Having a test does not prevent the API to be changed. It just ensure that
it is changed willingly as one would have to update the test in addition of
the API.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150816/24f3fd15/attachment.html>

On Sun, Aug 16, 2015 at 10:35 PM deadal nix <deadalnix at gmail.com>
wrote:
>
>
> 2015-08-16 21:51 GMT-07:00 Eric Christopher <echristo at gmail.com>:
>
>>
>>
>> On Sun, Aug 16, 2015 at 9:49 PM deadal nix <deadalnix at
gmail.com> wrote:
>>
>>> 2015-08-16 21:47 GMT-07:00 Eric Christopher <echristo at
gmail.com>:
>>>
>>>>
>>>>
>>>> On Sun, Aug 16, 2015 at 6:45 PM deadal nix via llvm-dev <
>>>> llvm-dev at lists.llvm.org> wrote:
>>>>
>>>>> Chiming in with http://reviews.llvm.org/D10725
>>>>>
>>>>> Being able to read and generate IR is at least some very
basic thing
>>>>> we can agree on is needed. Can we get some testing for it ?
Personally I
>>>>> don't really mind if this is going to be stable or not,
but at least,
>>>>> having some test coverage would allow to take whatever path
that is going
>>>>> to be taken willingly.
>>>>>
>>>>>
>>>> Right, and that's the problem. Expanding the C API to cover
reading and
>>>> generating IR in a stable way will lock the C++ API down in a
way that I'm
>>>> not comfortable with - I think it has already gone too far.
>>>>
>>>> -eric
>>>>
>>>
>>> That seems like a bare minimum.
>>>
>>> The C++ evolve from one version to another, what is preventing the
C API
>>> to do the same ?
>>>
>>>
>> The promise of stability. We don't promise that the C++ API will
stay
>> stable.
>>
>> -eric
>>
>
>
> Why was that promise be made in the first place ? Has it been made in the
> first place ?
>
>
Please read the rest of the thread :)

> Also, whether, the C API is stable or change between version, being able
> to read and write IR from it seems like a bare minimum and having test for
> this as well.
>
> Having a test does not prevent the API to be changed. It just ensure that
> it is changed willingly as one would have to update the test in addition of
> the API.
>
>
Your reading of this is not the same as anyone else's reading for what
would be considered stable.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150817/b4471577/attachment.html>

On Sun, Aug 16, 2015 at 10:34 PM, deadal nix via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
> 2015-08-16 21:51 GMT-07:00 Eric Christopher <echristo at gmail.com>:
>>
>> The promise of stability. We don't promise that the C++ API will
stay
>> stable.
>>
>
>
> Why was that promise be made in the first place ? Has it been made in the
> first place ?
>
It sounds like you're in favor of dropping C API stability then, if it's
holding us back? That feedback is actually really helpful. :)

There are really three goals here: flexibility to change LLVM IR,
completeness of the C API, and stability of the C API. Pick two.

The goals are mutually incompatible and we have to trade off one for the
other. Most of the LLVM core developers value goal #1, the ability to
change the IR. Look at the pointee type changes that David Blaikie is
working on, and the new EH representation. If we promise both stability and
completeness, these things are impossible.

One way forward is to guarantee stability, but limit completeness. This
would mean limiting the C API to constructs that will always and forever be
easily represented in LLVM.

The other choice is to forget stability and wrap the C++ API completely,
potentially with something auto-generated. We could make a more limited
stability promise along the lines of "these APIs will be updated to reflect
changes to the IR, and are otherwise stable." I think everyone would be
fine with that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150817/3c3a7f1f/attachment.html>