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

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>

On Fri, Dec 07, 2012 at 08:58:21PM +0000, Relph, Richard
wrote:
> 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.
> 
Hi Richard,

Do you want to support older versions of LLVM with just bug fixes, or
new features as well?

If you are just applying bug fixes to the older versions, then I think
the best way to handle this would be to maintain a separate LLVM tree
for each version.

However, if you want all versions to be more or less functionality
equivalent, then I think the only solution is to create a standalone
AMDIL codebase that can overlay on top of the LLVM tree.  You can't have
conditional code based on the LLVM version in the main tree, because
all code for the older versions of LLVM would be dead and this would impose
a heavy maintenance burden on the community.

-Tom

>     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
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On 12/07/2012 01:31 PM, Tom Stellard wrote:
> Do you want to support older versions of LLVM with just bug fixes, or
> new features as well?
>
> If you are just applying bug fixes to the older versions, then I think
> the best way to handle this would be to maintain a separate LLVM tree
> for each version.
I vote for this (s/tree/branch/)