llvm dev - Dec 2012 - [LLVMdev] Backends supporting multiple LLVM revisions...

Is there a convention for how the LLVM community prefers to have conditional
compilation in code intended to be checked in to llvm.org?

Our goal is a single code base that can support multiple LLVM revisions,
including LLVM TOT. In the long run, of course, we'll simply be able to
refer to the backend revision that corresponds to the revision of LLVM in use.
If fixes between TOT and that older version are desired, cherry-picking from
trunk will be required, of course.

But in the short run, that's not viable. We have to support a minimum of 3
different LLVM versions with our backend… LLVM TOT, the LLVM version used for
AMD's OpenCL as shipped for Windows and Linux, and the LLVM version used for
Apple's OpenCL as shipped for Mac OS… all different today and for the
foreseeable future.

Between the time that we get AMDIL "in" to llvm.org and the time that
the other platforms using AMDIL are up to the level of LLVM at that initial
check-in, we'll need to have conditional code in AMDIL.

Thanks,
Richard

Currently top of tree is top of tree and no backwards compatibility, other
than the C backend, is promised. I think that instead of asserting that you
need to check in conditional compilation for a backend, perhaps, you would
be open to other options to accomplish the same needs?

My suggestion would be to check in or make some branches for the two older
versions and then apply your patches on top of that, letting people know
where to get those sources so that they can build what they need. If this
won't work then perhaps you can explain why you think you need to have
multiple versions available in top of tree?

Thanks!

-eric


On Fri, Dec 7, 2012 at 10:08 AM, Relph, Richard <Richard.Relph at
amd.com>wrote:
> Is there a convention for how the LLVM community prefers to have
> conditional compilation in code intended to be checked in to llvm.org?
>
> Our goal is a single code base that can support multiple LLVM revisions,
> including LLVM TOT. In the long run, of course, we'll simply be able to
> refer to the backend revision that corresponds to the revision of LLVM in
> use. If fixes between TOT and that older version are desired,
> cherry-picking from trunk will be required, of course.
>
> But in the short run, that's not viable. We have to support a minimum
of 3
> different LLVM versions with our backend… LLVM TOT, the LLVM version used
> for AMD's OpenCL as shipped for Windows and Linux, and the LLVM version
> used for Apple's OpenCL as shipped for Mac OS… all different today and
for
> the foreseeable future.
>
> Between the time that we get AMDIL "in" to llvm.org and the time
that the
> other platforms using AMDIL are up to the level of LLVM at that initial
> check-in, we'll need to have conditional code in AMDIL.
>
> Thanks,
> Richard
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121207/06bff7ff/attachment.html>

On Fri, Dec 7, 2012 at 11:01 AM, Eric Christopher <echristo at
gmail.com>wrote:
> Currently top of tree is top of tree and no backwards compatibility, other
> than the C backend,

C API not C Backend. The C Backend doesn't exist anymore.

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

Richard, 

We're in a similar situation.  We sit in the middle of clang and LLC and
moving to a strict TOT development plan has become our way forward.

Still, I'm deeply interested in solving this problem at some level. 
We've even considered building an API layer on top of LLVM to be able to
selectively choose between 3.0, 3.1, 3.2, ToT, etc.

I'm going to investigate the C API, as I've now heard two people speak
to this as a possible solution.

I'd be interested in hearing more details about your need for conditional
compilation, I presume it's around the need to change things like functions
whose parameter list has change, type renames, etc.

Joe

On Dec 7, 2012, at 1:08 PM, "Relph, Richard" <Richard.Relph at
amd.com> wrote:
> Is there a convention for how the LLVM community prefers to have
conditional compilation in code intended to be checked in to llvm.org?
> 
> Our goal is a single code base that can support multiple LLVM revisions,
including LLVM TOT. In the long run, of course, we'll simply be able to
refer to the backend revision that corresponds to the revision of LLVM in use.
If fixes between TOT and that older version are desired, cherry-picking from
trunk will be required, of course.
> 
> But in the short run, that's not viable. We have to support a minimum
of 3 different LLVM versions with our backend… LLVM TOT, the LLVM version used
for AMD's OpenCL as shipped for Windows and Linux, and the LLVM version used
for Apple's OpenCL as shipped for Mac OS… all different today and for the
foreseeable future.
> 
> Between the time that we get AMDIL "in" to llvm.org and the time
that the other platforms using AMDIL are up to the level of LLVM at that initial
check-in, we'll need to have conditional code in AMDIL.
> 
> Thanks,
> Richard
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Eric,
    Once both AMD and Apple have advanced their respective internal LLVM
versions past the point where AMDIL went in to LLVM TOT, then we can rip out all
the conditional code and just have the one LLVM TOT. This is about managing the
transition to that utopia… ;-)
    Until then, the choices really come down to having support for multiple LLVM
versions in TOT, or having multiple backends.
    The problem arises because we were not able to get AMDIL in to
llvm.org<http://llvm.org> from the very beginning, but we now have 2
"customers" - each with their own non-standard LLVM version - using
AMDIL and we cannot abandon them. And they dictate the LLVM version they are
going to use, not us.

    I'm more than willing to consider alternatives… your suggestion, if I
read it correctly, is basically to maintain the 3 versions separately and in
parallel until such time as the others are up to the point that LLVM was when
AMDIL goes in. (Ya, I don't think I got all the tenses right in that
sentence… I hope you get my drift. ;-) I'd really like an alternative other
than to having to maintain multiple backends for what will probably 6 months to
a year. We're spread pretty thin now.

Thanks,
Richard

On Dec 7, 2012, at 11:01 AM, Eric Christopher <echristo at
gmail.com<mailto:echristo at gmail.com>> wrote:

Currently top of tree is top of tree and no backwards compatibility, other than
the C backend, is promised. I think that instead of asserting that you need to
check in conditional compilation for a backend, perhaps, you would be open to
other options to accomplish the same needs?

My suggestion would be to check in or make some branches for the two older
versions and then apply your patches on top of that, letting people know where
to get those sources so that they can build what they need. If this won't
work then perhaps you can explain why you think you need to have multiple
versions available in top of tree?

Thanks!

-eric


On Fri, Dec 7, 2012 at 10:08 AM, Relph, Richard <Richard.Relph at
amd.com<mailto:Richard.Relph at amd.com>> wrote:
Is there a convention for how the LLVM community prefers to have conditional
compilation in code intended to be checked in to
llvm.org<http://llvm.org/>?

Our goal is a single code base that can support multiple LLVM revisions,
including LLVM TOT. In the long run, of course, we'll simply be able to
refer to the backend revision that corresponds to the revision of LLVM in use.
If fixes between TOT and that older version are desired, cherry-picking from
trunk will be required, of course.

But in the short run, that's not viable. We have to support a minimum of 3
different LLVM versions with our backend… LLVM TOT, the LLVM version used for
AMD's OpenCL as shipped for Windows and Linux, and the LLVM version used for
Apple's OpenCL as shipped for Mac OS… all different today and for the
foreseeable future.

Between the time that we get AMDIL "in" to
llvm.org<http://llvm.org/> and the time that the other platforms using
AMDIL are up to the level of LLVM at that initial check-in, we'll need to
have conditional code in AMDIL.

Thanks,
Richard

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu<http://llvm.cs.uiuc.edu/>
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121207/90e49f0e/attachment.html>