[LLVMdev] Backends supporting multiple LLVM revisions...

[Joe Abbey]

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