llvm dev - Jul 2013 - [LLVMdev] Advice to API inconsistency between different versions

Hello all,

LLVM's API varies a lot from version to version. Take a example, header
llvm/Target/TargetData.h changed to llvm/DataLayout.h from LLVM version 3.1
to version 3.2. This sliced the program just like:

#if defined(LLVM_V31)
  #include llvm/Target/TargetData.h
#elif defined(LLVM_V32)
  #include llvm/DataLayout.h
#else
  #error NEED HEADER

The code is in a mess if I want to support previous LLVM version. I am
wondering how do you support different LLVM versions and keep the code
clean as well?

On the other hand, consider the example above. Do you usually check for
LLVM version (ex. LLVM_V31, LLVM_V32) or check for feature instead, which
use m4 AC_CHECK_HEADER to detect whether the header exist during
configuration?

Thanks a lot
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130722/09c958cb/attachment.html>

On Mon, Jul 22, 2013 at 2:21 AM, lyh.kernel <lyh.kernel at gmail.com>
wrote:
> Hello all,
>
> LLVM's API varies a lot from version to version. Take a example, header
> llvm/Target/TargetData.h changed to llvm/DataLayout.h from LLVM version 3.1
> to version 3.2. This sliced the program just like:
>
> #if defined(LLVM_V31)
>   #include llvm/Target/TargetData.h
> #elif defined(LLVM_V32)
>   #include llvm/DataLayout.h
> #else
>   #error NEED HEADER
>
> The code is in a mess if I want to support previous LLVM version. I am
> wondering how do you support different LLVM versions and keep the code
clean
> as well?
>
> On the other hand, consider the example above. Do you usually check for
LLVM
> version (ex. LLVM_V31, LLVM_V32) or check for feature instead, which use m4
> AC_CHECK_HEADER to detect whether the header exist during configuration?
>
> Thanks a lot
Greetings,

My company investigated using a LLVM shim/wrapper to paper over API
differences between versions. We eventually concluded that our
development time was better spent staying on ToT and taking advantage
of IR's (so far) forward compatibility to consume IR generated by
older versions. Luckily, we don't have to worry about our output IR
being consumed by anything but our ToT llc.

Cheers,
Jevin