llvm dev - Feb 2010 - [LLVMdev] Changes in FunctionPassManager constructor

What guarantees does LLVM try to provide regarding source code compatibility?

Case in point: rev 94686
(http://llvm.org/viewvc/llvm-project?view=rev&revision=94686) breaks any
code that creates a JIT. For example, we used to construct a FunctionPassManager
with a ModuleProvider, it's now to be done with a Module. I cannot ship
source code for my own project that is compatible with both pre-94686 and
post-94686.

This seems to be relatively frequent in LLVM. My project is not very active, and
it's relatively young, but I think this is the third time it hits us. At
some point i had to add InitializeNativeTarget(). At some other point, I had to
add "context" everywhere. And then there was another issue with
globals that eludes me right now. Anyway, I have to assume that preserving
source-code compatibility is a non-objective.

I could not find any documentation about what the "policy" for C++ is.
The check-in for 94686 seems to suggest that the C bindings are somewhat
preserved, but doesn't it make sense to provide some guarantees regarding
the most frequently used C++ code?

Also note that the documentation is unintentionally misleading. It's very
confusing for http://llvm.org/docs/tutorial/LangImpl4.html to show "Last
modified: $Date: 2007-10-17 11:05:13 -0700 (Wed, 17 Oct 2007) $" at the
bottom, as if nothing had changed since then, when the code it displays is
actually less than a week old... I guess the source code snippets are updated
automagically. As a result, the code shown there as an example will NOT compile
on anything but a most recent LLVM, i.e. it will not work if you install LLVM
with apt-get or MacPorts. I don't think that's desirable.

Opinions?


Christophe de Dinechin

On Wed, Feb 3, 2010 at 8:34 AM, Christophe de Dinechin
<christophe at taodyne.com> wrote:
> What guarantees does LLVM try to provide regarding source code
compatibility?
None.
> Also note that the documentation is unintentionally misleading. It's
very confusing for http://llvm.org/docs/tutorial/LangImpl4.html to show
"Last modified: $Date: 2007-10-17 11:05:13 -0700 (Wed, 17 Oct 2007) $"
at the bottom, as if nothing had changed since then, when the code it displays
is actually less than a week old... I guess the source code snippets are updated
automagically. As a result, the code shown there as an example will NOT compile
on anything but a most recent LLVM, i.e. it will not work if you install LLVM
with apt-get or MacPorts. I don't think that's desirable.
That's the docs for trunk; to get docs for a specific release, try,
for example, http://llvm.org/releases/2.6/docs/tutorial/LangImpl4.html
.

-Eli

Hi Christophe,

So this is a pain, but we are dealing with a pre-release. Until the 2.7 freeze
the source should continue to churn.

Regards

Garrison

On Feb 3, 2010, at 11:34, Christophe de Dinechin wrote:
> What guarantees does LLVM try to provide regarding source code
compatibility?
> 
> Case in point: rev 94686
(http://llvm.org/viewvc/llvm-project?view=rev&revision=94686) breaks any
code that creates a JIT. For example, we used to construct a FunctionPassManager
with a ModuleProvider, it's now to be done with a Module. I cannot ship
source code for my own project that is compatible with both pre-94686 and
post-94686.
> 
> This seems to be relatively frequent in LLVM. My project is not very
active, and it's relatively young, but I think this is the third time it
hits us. At some point i had to add InitializeNativeTarget(). At some other
point, I had to add "context" everywhere. And then there was another
issue with globals that eludes me right now. Anyway, I have to assume that
preserving source-code compatibility is a non-objective.
> 
> I could not find any documentation about what the "policy" for
C++ is. The check-in for 94686 seems to suggest that the C bindings are somewhat
preserved, but doesn't it make sense to provide some guarantees regarding
the most frequently used C++ code?
> 
> Also note that the documentation is unintentionally misleading. It's
very confusing for http://llvm.org/docs/tutorial/LangImpl4.html to show
"Last modified: $Date: 2007-10-17 11:05:13 -0700 (Wed, 17 Oct 2007) $"
at the bottom, as if nothing had changed since then, when the code it displays
is actually less than a week old... I guess the source code snippets are updated
automagically. As a result, the code shown there as an example will NOT compile
on anything but a most recent LLVM, i.e. it will not work if you install LLVM
with apt-get or MacPorts. I don't think that's desirable.
> 
> Opinions?
> 
> 
> Christophe de Dinechin
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

So, it looks like I mis-read this. You were referring to backward compatibility.

Garrison

On Feb 3, 2010, at 12:11, Garrison Venn wrote:
> Hi Christophe,
> 
> So this is a pain, but we are dealing with a pre-release. Until the 2.7
freeze the source should continue to churn.
> 
> Regards
> 
> Garrison
> 
> On Feb 3, 2010, at 11:34, Christophe de Dinechin wrote:
> 
>> What guarantees does LLVM try to provide regarding source code
compatibility?
>> 
>> Case in point: rev 94686
(http://llvm.org/viewvc/llvm-project?view=rev&revision=94686) breaks any
code that creates a JIT. For example, we used to construct a FunctionPassManager
with a ModuleProvider, it's now to be done with a Module. I cannot ship
source code for my own project that is compatible with both pre-94686 and
post-94686.
>> 
>> This seems to be relatively frequent in LLVM. My project is not very
active, and it's relatively young, but I think this is the third time it
hits us. At some point i had to add InitializeNativeTarget(). At some other
point, I had to add "context" everywhere. And then there was another
issue with globals that eludes me right now. Anyway, I have to assume that
preserving source-code compatibility is a non-objective.
>> 
>> I could not find any documentation about what the "policy"
for C++ is. The check-in for 94686 seems to suggest that the C bindings are
somewhat preserved, but doesn't it make sense to provide some guarantees
regarding the most frequently used C++ code?
>> 
>> Also note that the documentation is unintentionally misleading.
It's very confusing for http://llvm.org/docs/tutorial/LangImpl4.html to show
"Last modified: $Date: 2007-10-17 11:05:13 -0700 (Wed, 17 Oct 2007) $"
at the bottom, as if nothing had changed since then, when the code it displays
is actually less than a week old... I guess the source code snippets are updated
automagically. As a result, the code shown there as an example will NOT compile
on anything but a most recent LLVM, i.e. it will not work if you install LLVM
with apt-get or MacPorts. I don't think that's desirable.
>> 
>> Opinions?
>> 
>> 
>> Christophe de Dinechin
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

On 3 févr. 2010, at 17:54, Eli Friedman wrote:
> On Wed, Feb 3, 2010 at 8:34 AM, Christophe de Dinechin
> <christophe at taodyne.com> wrote:
>> What guarantees does LLVM try to provide regarding source code
compatibility?
> 
> None.
And this is a good thing because... ?

Christophe

>> Also note that the documentation is unintentionally misleading.
It's very confusing for http://llvm.org/docs/tutorial/LangImpl4.html to show
"Last modified: $Date: 2007-10-17 11:05:13 -0700 (Wed, 17 Oct 2007) $"
at the bottom, as if nothing had changed since then, when the code it displays
is actually less than a week old... I guess the source code snippets are updated
automagically. As a result, the code shown there as an example will NOT compile
on anything but a most recent LLVM, i.e. it will not work if you install LLVM
with apt-get or MacPorts. I don't think that's desirable.
> 
> That's the docs for trunk; to get docs for a specific release, try,
> for example, http://llvm.org/releases/2.6/docs/tutorial/LangImpl4.html
These are the docs I get by default if I click on "documentation" then
"Tutorial" then ... or if I use Google. How is a poor schmuck trying
to build his first LLVM tool supposed to figure out that the documentation is
not "the right one"?

Christophe

On Feb 3, 2010, at 8:34 AM, Christophe de Dinechin
wrote:
> Also note that the documentation is unintentionally misleading. It's
very confusing for http://llvm.org/docs/tutorial/LangImpl4.html to show
"Last modified: $Date: 2007-10-17 11:05:13 -0700 (Wed, 17 Oct 2007) $"
at the bottom, as if nothing had changed since then, when the code it displays
is actually less than a week old... I guess the source code snippets are updated
automagically. As a result, the code shown there as an example will NOT compile
on anything but a most recent LLVM, i.e. it will not work if you install LLVM
with apt-get or MacPorts. I don't think that's desirable.
This particular issue is now fixed. Unfortunately it means that all the
"Last modified" dates on those pages are now today rather than their
last
real modification, but theoretically they should now stay current with
future changes.

Dan

That's much better. Thanks a lot.

Christophe

On 3 févr. 2010, at 19:37, Dan Gohman wrote:
> 
> On Feb 3, 2010, at 8:34 AM, Christophe de Dinechin wrote:
>> Also note that the documentation is unintentionally misleading.
It's very confusing for http://llvm.org/docs/tutorial/LangImpl4.html to show
"Last modified: $Date: 2007-10-17 11:05:13 -0700 (Wed, 17 Oct 2007) $"
at the bottom, as if nothing had changed since then, when the code it displays
is actually less than a week old... I guess the source code snippets are updated
automagically. As a result, the code shown there as an example will NOT compile
on anything but a most recent LLVM, i.e. it will not work if you install LLVM
with apt-get or MacPorts. I don't think that's desirable.
> 
> This particular issue is now fixed. Unfortunately it means that all the
> "Last modified" dates on those pages are now today rather than
their last
> real modification, but theoretically they should now stay current with
> future changes.
> 
> Dan
>