[llvm-dev] Custom call lowering - where?
Jon Chesterfield via llvm-dev
llvm-dev at lists.llvm.org
Thu Aug 10 11:25:35 PDT 2017
I've made reasonable progress with this. CallingConv.td appears to be a
description of what the call lowering is going to do, not a means of
altering the DAG. The target functions LowerCall, LowerFormalArguments,
LowerReturn control the DAG modifications.
Intercepting the SDValues en route to and from the call in these three
functions appears to suffice. Looks a bit hackish though, better
suggestions still welcome.
Cheers
On Thu, Aug 10, 2017 at 4:52 PM, via llvm-dev <llvm-dev at lists.llvm.org>
wrote:
> Send llvm-dev mailing list submissions to
> llvm-dev at lists.llvm.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> or, via email, send a message with subject or body 'help' to
> llvm-dev-request at lists.llvm.org
>
> You can reach the person managing the list at
> llvm-dev-owner at lists.llvm.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of llvm-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: PHI nodes and connected ICMp
> (Anastasiya Ruzhanskaya via llvm-dev)
> 2. Re: PHI nodes and connected ICMp
> (Anastasiya Ruzhanskaya via llvm-dev)
> 3. Custom call lowering - where? (Jon Chesterfield via llvm-dev)
> 4. Re: [poison] re: is select-of-select to logic+select allowed
> ? (Dan Liew via llvm-dev)
> 5. llvm-5.0: couldn't build libomptarget (Siegmar Gross via llvm-dev)
> 6. Re: llvm-5.0: couldn't build libomptarget
> (Jonas Hahnfeld via llvm-dev)
> 7. Re: InstCombine GEP (Nuno Lopes via llvm-dev)
> 8. Re: [ThinLTO] Suggestions on how to traverse SCCs in the
> Module Summary Index bottom up (Charles Saternos via llvm-dev)
> 9. Re: Relicensing: Revised Developer Policy
> (Rafael Avila de Espindola via llvm-dev)
> 10. Re: Relicensing: Revised Developer Policy
> (Chris Lattner via llvm-dev)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 10 Aug 2017 10:00:49 +0200
> From: Anastasiya Ruzhanskaya via llvm-dev <llvm-dev at lists.llvm.org>
> To: Sanjoy Das <sanjoy at google.com>
> Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] PHI nodes and connected ICMp
> Message-ID:
> <CAH7gUZYfXvymt7gYfyqg1-szb2FKF6tJ7_tNhzWP3jpPVGqzQw@
> mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Maybe you, as a person connected with this theme, have some
> recommendations? Analyzing SCEV didn't help me, as I am not able to extract
> information, that is crucial for me.
>
> 2017-08-10 9:55 GMT+02:00 Anastasiya Ruzhanskaya <
> anastasiya.ruzhanskaya at frtk.ru>:
>
> > Hi!
> > By only two cases I mean , that in exiting block when computing the
> > condition related to PHI node I can expect only icmp on one of incoming
> > values or on phi node itself... I tried to come up with some more complex
> > examples but I always receive only these two cases, that is why I am
> asking.
> >
> > This problem still relates to the problem of all induction, cumulative
> and
> > so on variables in loop. SCEV didn't help me, as it doesn't provide me
> with
> > the value against which I am comparing when exiting, and when it cannot
> > detect loop trip count directly I need this "exiting value". That is why
> I
> > am searching for all compare instructions in exiting blocks that are
> using
> > either "phi" itself or "incoming value".
> >
> > 2017-08-10 9:47 GMT+02:00 Sanjoy Das <sanjoy at google.com>:
> >
> >> It may be helpful to see the incoming value as the incoming value of
> >> the "next" PHI (i.e. the instance of the PHI node on the next
> >> iteration). With that interpretation in mind, you can see that
> >> comparing the PHI node itself is equivalent to:
> >>
> >> do {
> >> ...
> >> // I is the value that becomes the PHI node
> >> } while (I++ < N);
> >>
> >> and comparing with the incoming value of the PHI is equivalent to:
> >>
> >> do {
> >> ...
> >> } while (++I < N);
> >>
> >>
> >> I can't think of any fundamental reason why one would be preferred for
> >> increasing induction variables and the other would be preferred for
> >> decreasing induction variables. I suspect what you're seeing is just
> >> an artifact of how clang lowers these loops.
> >>
> >> I'm also not sure what you mean by "I can have only two cases". Loop
> >> backedge conditions can be arbitrarily complex, if that's what you're
> >> asking.
> >>
> >> -- Sanjoy
> >>
> >>
> >> On Thu, Aug 10, 2017 at 12:34 AM, Anastasiya Ruzhanskaya via llvm-dev
> >> <llvm-dev at lists.llvm.org> wrote:
> >> > Hello,
> >> > I have one more question about how phi nodes and their corresponding
> >> ICmp
> >> > instructions are associated. maybe it is simple, but at first I
> thought
> >> that
> >> > we always compare against one of incoming value. Is it true that I
> can
> >> have
> >> > only two cases:
> >> > %indvars.iv = phi i64 [ %indvars.iv.next, %1 ], [ 0, %0 ]
> >> > ...
> >> > %indvars.iv.next = add nuw nsw i64 %indvars.iv, 1
> >> > %exitcond = icmp eq i64 %indvars.iv.next, 32
> >> >
> >> >
> >> > and
> >> >
> >> > %i.11 = phi i32 [ %i.11.be, %.backedge ], [ 32, %1 ]
> >> > ...
> >> > %13 = icmp sgt i32 %i.11, 3
> >> > ?
> >> > In the first one we always have icmp on the incoming value after
> >> addition,
> >> > multiplication and so on.
> >> > In the second - we compare at first against our phi variable and then
> >> > perform operations. I have noticed, that the first case correspond to
> >> "up"
> >> > operations - +=, *= ans do on, the second - to "down" : -=, /= and so
> >> on.
> >> > But maybe it depends on logic of the cycle too... So, are their two
> >> cases :
> >> > comparing in exiting block against PHI variable or against one of its'
> >> > incoming value?
> >> >
> >> > _______________________________________________
> >> > LLVM Developers mailing list
> >> > llvm-dev at lists.llvm.org
> >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >> >
> >>
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/llvm-dev/
> attachments/20170810/87946d0c/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 10 Aug 2017 10:27:47 +0200
> From: Anastasiya Ruzhanskaya via llvm-dev <llvm-dev at lists.llvm.org>
> To: Sanjoy Das <sanjoy at google.com>
> Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] PHI nodes and connected ICMp
> Message-ID:
> <CAH7gUZYv98MNhyWpR=wxk2=_3YKSaCfP-AF8hn7qx7=LYam4LA@
> mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Also, even when not using canonical induction variables, and extracting max
> backedge taken count, then I can't determine to which phi instruction ( if
> I have many of them in cycle) this backedge taken count relates to (as Loop
> can only provide me with canonical variable and SCEV gives a description of
> PHI). Or maybe again I didn't find an appropriate method to extract this
> phi node, which gives this count.
>
> 2017-08-10 10:00 GMT+02:00 Anastasiya Ruzhanskaya <
> anastasiya.ruzhanskaya at frtk.ru>:
>
> > Maybe you, as a person connected with this theme, have some
> > recommendations? Analyzing SCEV didn't help me, as I am not able to
> extract
> > information, that is crucial for me.
> >
> > 2017-08-10 9:55 GMT+02:00 Anastasiya Ruzhanskaya <
> > anastasiya.ruzhanskaya at frtk.ru>:
> >
> >> Hi!
> >> By only two cases I mean , that in exiting block when computing the
> >> condition related to PHI node I can expect only icmp on one of incoming
> >> values or on phi node itself... I tried to come up with some more
> complex
> >> examples but I always receive only these two cases, that is why I am
> asking.
> >>
> >> This problem still relates to the problem of all induction, cumulative
> >> and so on variables in loop. SCEV didn't help me, as it doesn't provide
> me
> >> with the value against which I am comparing when exiting, and when it
> >> cannot detect loop trip count directly I need this "exiting value".
> That is
> >> why I am searching for all compare instructions in exiting blocks that
> are
> >> using either "phi" itself or "incoming value".
> >>
> >> 2017-08-10 9:47 GMT+02:00 Sanjoy Das <sanjoy at google.com>:
> >>
> >>> It may be helpful to see the incoming value as the incoming value of
> >>> the "next" PHI (i.e. the instance of the PHI node on the next
> >>> iteration). With that interpretation in mind, you can see that
> >>> comparing the PHI node itself is equivalent to:
> >>>
> >>> do {
> >>> ...
> >>> // I is the value that becomes the PHI node
> >>> } while (I++ < N);
> >>>
> >>> and comparing with the incoming value of the PHI is equivalent to:
> >>>
> >>> do {
> >>> ...
> >>> } while (++I < N);
> >>>
> >>>
> >>> I can't think of any fundamental reason why one would be preferred for
> >>> increasing induction variables and the other would be preferred for
> >>> decreasing induction variables. I suspect what you're seeing is just
> >>> an artifact of how clang lowers these loops.
> >>>
> >>> I'm also not sure what you mean by "I can have only two cases". Loop
> >>> backedge conditions can be arbitrarily complex, if that's what you're
> >>> asking.
> >>>
> >>> -- Sanjoy
> >>>
> >>>
> >>> On Thu, Aug 10, 2017 at 12:34 AM, Anastasiya Ruzhanskaya via llvm-dev
> >>> <llvm-dev at lists.llvm.org> wrote:
> >>> > Hello,
> >>> > I have one more question about how phi nodes and their corresponding
> >>> ICmp
> >>> > instructions are associated. maybe it is simple, but at first I
> >>> thought that
> >>> > we always compare against one of incoming value. Is it true that I
> >>> can have
> >>> > only two cases:
> >>> > %indvars.iv = phi i64 [ %indvars.iv.next, %1 ], [ 0, %0 ]
> >>> > ...
> >>> > %indvars.iv.next = add nuw nsw i64 %indvars.iv, 1
> >>> > %exitcond = icmp eq i64 %indvars.iv.next, 32
> >>> >
> >>> >
> >>> > and
> >>> >
> >>> > %i.11 = phi i32 [ %i.11.be, %.backedge ], [ 32, %1 ]
> >>> > ...
> >>> > %13 = icmp sgt i32 %i.11, 3
> >>> > ?
> >>> > In the first one we always have icmp on the incoming value after
> >>> addition,
> >>> > multiplication and so on.
> >>> > In the second - we compare at first against our phi variable and then
> >>> > perform operations. I have noticed, that the first case correspond to
> >>> "up"
> >>> > operations - +=, *= ans do on, the second - to "down" : -=, /= and so
> >>> on.
> >>> > But maybe it depends on logic of the cycle too... So, are their two
> >>> cases :
> >>> > comparing in exiting block against PHI variable or against one of
> its'
> >>> > incoming value?
> >>> >
> >>> > _______________________________________________
> >>> > LLVM Developers mailing list
> >>> > llvm-dev at lists.llvm.org
> >>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>> >
> >>>
> >>
> >>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/llvm-dev/
> attachments/20170810/a6ae6f34/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 10 Aug 2017 09:49:05 +0100
> From: Jon Chesterfield via llvm-dev <llvm-dev at lists.llvm.org>
> To: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: [llvm-dev] Custom call lowering - where?
> Message-ID:
> <CAOUYtQAUBdRgWzgXx=vDmOUe=7-DEUXd1A1=J0vuLTzn-CywTA at mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> The CallingConv.td file can specify CCCustom and ISelLowering has
> LowerFormalArguments. The existing uses of CCCustom pick a register to pass
> an unmodified argument in and LowerFormalArguments is mostly concerned with
> marking registers as live, though I think provides enough information that
> I can munge the DAG there.
>
> I would like to pass a scalar type (marked as a register class) in a vector
> register. I essentially want to wrap the argument in a SCALAR_TO_VECTOR ISD
> node before calling a function and unwrap it using EXTRACT_VECTOR_ELT or
> similar within the function.
>
> Where should I introduce these additional nodes, or should it be possible
> to achieve this via CCCustom?
>
> Cheers!
>
> Jon
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/llvm-dev/
> attachments/20170810/24172886/attachment-0001.html>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 10 Aug 2017 09:59:06 +0100
> From: Dan Liew via llvm-dev <llvm-dev at lists.llvm.org>
> To: Peter Lawrence <peterl95124 at sbcglobal.net>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] [poison] re: is select-of-select to
> logic+select allowed ?
> Message-ID:
> <CAJ7DczHLK0VnCmQpAUGeJWR5+rFQTYH8oi0oZFbnaqVnOSt+Gg@
> mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On 7 June 2017 at 04:25, Peter Lawrence via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Nuno,
> > Sanjoy,
> > Can you provide some actual C source code examples that show
> how
> > End-to-end-miscompilations have resulted from the presence of “UB” in
> > Select statements ?
>
> We hit an example of this recently. See
> https://bugs.llvm.org/show_bug.cgi?id=34133
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 10 Aug 2017 11:52:52 +0200
> From: Siegmar Gross via llvm-dev <llvm-dev at lists.llvm.org>
> To: llvm-dev at lists.llvm.org
> Subject: [llvm-dev] llvm-5.0: couldn't build libomptarget
> Message-ID:
> <486b1da4-c287-03ed-ccbc-71f27b8675c2 at informatik.hs-fulda.de>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi,
>
> I've built llvm-5.0 with some projects (gcc-5.3.0 necessary for CUDA)
> on my "SUSE Linux Enterprise Server 12.2 (x86_64)". Unfortunately,
> the project libomptarget wasn't built, while I could build it some
> weeks ago in llvm-trunk.
>
>
> loki fd1026 107 clang -v
> clang version 5.0.0 (branches/release_50 310550)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> InstalledDir: /usr/local/llvm-5.0/bin
> Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/4.8
> Selected GCC installation: /usr/lib64/gcc/x86_64-suse-linux/4.8
> Candidate multilib: .;@m64
> Candidate multilib: 32;@m32
> Selected multilib: .;@m64
> Found CUDA installation: /usr/local/cuda, version 8.0
>
> loki fd1026 108 find /usr/local/llvm-5.0/ -name '*omptarget*'
> loki fd1026 109 tar zvft /usr/local/llvm-trunk_working.tar.gz | grep
> omptarget
> -rwxr-xr-x root/root 20176 2017-07-17 17:56
> llvm-trunk/lib64/libomptarget.rtl.x86_64.so
> -rwxr-xr-x root/root 25840 2017-07-17 17:56
> llvm-trunk/lib64/libomptarget.rtl.cuda.so
> -rwxr-xr-x root/root 81360 2017-07-17 17:56
> llvm-trunk/lib64/libomptarget.so
> loki fd1026 110
>
>
> I've used the following commands to configure and build everything.
>
> svn co http://llvm.org/svn/llvm-project/llvm/branches/release_50 llvm
> cd llvm/tools
> svn co http://llvm.org/svn/llvm-project/cfe/branches/release_50 clang
> svn co http://llvm.org/svn/llvm-project/polly/branches/release_50 polly
> cd clang/tools
> svn co http://llvm.org/svn/llvm-project/clang-tools-extra/
> branches/release_50/ extra
> cd ../../../projects
> svn co http://llvm.org/svn/llvm-project/compiler-rt/branches/release_50
> compiler-rt
> svn co http://llvm.org/svn/llvm-project/openmp/branches/release_50 openmp
> svn co https://github.com/clang-ykt/openmp libomptarget
>
>
> mkdir build
> cd build
> cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr/local/${LLVM_VERSION} \
> -GNinja \
> -DLLVM_TARGETS_TO_BUILD:STRING="NVPTX;X86" \
> -DCMAKE_BUILD_TYPE:STRING="Release" \
> -DLLVM_PARALLEL_COMPILE_JOBS:STRING="4" \
> -DLLVM_PARALLEL_LINK_JOBS:STRING="4" \
> -DCMAKE_C_COMPILER:STRING="${DIRPREFIX_PROG}/${GCCDIR}/bin/gcc" \
> -DCMAKE_C_FLAGS:STRING="-m64 -I/usr/local/valgrind/include" \
> -DCMAKE_CXX_COMPILER:STRING="${DIRPREFIX_PROG}/${GCCDIR}/bin/g++" \
> -DCMAKE_CXX_FLAGS:STRING="-m64 -I/usr/local/valgrind/include" \
> -DCMAKE_EXE_LINKER_FLAGS:STRING="-m64" \
> -DLLVM_LIBDIR_SUFFIX:STRING="64" \
> -DLLVM_POLLY_LINK_INTO_TOOLS:BOOL=ON \
>
> -DLIBOMPTARGET_DEP_LIBELF_INCLUDE_DIR:STRING="/usr/local/elfutils-0.169/include"
> \
>
> -DLIBOMPTARGET_DEP_LIBELF_LIBRARIES:STRING="/usr/local/
> elfutils-0.169/lib64/libelf.so"
> \
> -DLIBOMPTARGET_DEP_LIBFFI_INCLUDE_DIR:STRING="/usr/include" \
> -DLIBOMPTARGET_DEP_LIBFFI_LIBRARIES:STRING="/usr/lib64/libffi.so" \
> -DCUDA_INCLUDE_DIRS:STRING="/usr/local/cuda/include" \
> -DCUDA_LIBRARIES:STRING="/usr/local/cuda/lib64/libcudart.so" \
> -DBUILD_SHARED_LIBS:BOOL=ON \
> ../llvm \
> |& tee log.cmake
>
> ninja |& tee log.ninja-build
> ninja check |& tee log.ninja-check
> ninja install |& tee log.ninja-install
>
> loki build 217 tail -11 log.cmake
> Manually-specified variables were not used by the project:
> CUDA_INCLUDE_DIRS
> CUDA_LIBRARIES
> LIBOMPTARGET_DEP_LIBELF_INCLUDE_DIR
> LIBOMPTARGET_DEP_LIBELF_LIBRARIES
> LIBOMPTARGET_DEP_LIBFFI_INCLUDE_DIR
> LIBOMPTARGET_DEP_LIBFFI_LIBRARIES
> -- Build files have been written to: /export2/src/llvm-5.0/build
>
> loki build 218 grep -i omptarget log.*
> log.cmake: LIBOMPTARGET_DEP_LIBELF_INCLUDE_DIR
> log.cmake: LIBOMPTARGET_DEP_LIBELF_LIBRARIES
> log.cmake: LIBOMPTARGET_DEP_LIBFFI_INCLUDE_DIR
> log.cmake: LIBOMPTARGET_DEP_LIBFFI_LIBRARIES
> loki build 219
>
>
> Isn't libomptarget supported any longer? Do I have to change something in
> my checkout or configuration? I would be grateful if somebody can answer
> my questions. Please let me know if you need anything else. Thank you very
> much for any help in advance.
>
>
> Kind regards
>
> Siegmar
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 10 Aug 2017 12:17:39 +0200
> From: Jonas Hahnfeld via llvm-dev <llvm-dev at lists.llvm.org>
> To: Siegmar Gross <siegmar.gross at informatik.hs-fulda.de>
> Cc: llvm-dev at lists.llvm.org, openmp-dev at lists.llvm.org
> Subject: Re: [llvm-dev] llvm-5.0: couldn't build libomptarget
> Message-ID: <726a0e53c14e423615f81e49985af5d9 at hahnjo.de>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hi,
>
> +openmp-dev for discussion about runtime libraries.
>
> libomptarget has been disabled until the tests pass and that change has
> been merged for 5.0.
> If you really want it to build specify -DOPENMP_ENABLE_LIBOMPTARGET=On.
> As a side node: Currently, the committed code only allows offloading to
> the host, not yet to NVIDIA GPUs.
>
> Cheers,
> Jonas
>
> Am 2017-08-10 11:52, schrieb Siegmar Gross via llvm-dev:
> > Hi,
> >
> > I've built llvm-5.0 with some projects (gcc-5.3.0 necessary for CUDA)
> > on my "SUSE Linux Enterprise Server 12.2 (x86_64)". Unfortunately,
> > the project libomptarget wasn't built, while I could build it some
> > weeks ago in llvm-trunk.
> >
> >
> > loki fd1026 107 clang -v
> > clang version 5.0.0 (branches/release_50 310550)
> > Target: x86_64-unknown-linux-gnu
> > Thread model: posix
> > InstalledDir: /usr/local/llvm-5.0/bin
> > Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/4.8
> > Selected GCC installation: /usr/lib64/gcc/x86_64-suse-linux/4.8
> > Candidate multilib: .;@m64
> > Candidate multilib: 32;@m32
> > Selected multilib: .;@m64
> > Found CUDA installation: /usr/local/cuda, version 8.0
> >
> > loki fd1026 108 find /usr/local/llvm-5.0/ -name '*omptarget*'
> > loki fd1026 109 tar zvft /usr/local/llvm-trunk_working.tar.gz | grep
> > omptarget
> > -rwxr-xr-x root/root 20176 2017-07-17 17:56
> > llvm-trunk/lib64/libomptarget.rtl.x86_64.so
> > -rwxr-xr-x root/root 25840 2017-07-17 17:56
> > llvm-trunk/lib64/libomptarget.rtl.cuda.so
> > -rwxr-xr-x root/root 81360 2017-07-17 17:56
> > llvm-trunk/lib64/libomptarget.so
> > loki fd1026 110
> >
> >
> > I've used the following commands to configure and build everything.
> >
> > svn co http://llvm.org/svn/llvm-project/llvm/branches/release_50 llvm
> > cd llvm/tools
> > svn co http://llvm.org/svn/llvm-project/cfe/branches/release_50 clang
> > svn co http://llvm.org/svn/llvm-project/polly/branches/release_50 polly
> > cd clang/tools
> > svn co
> > http://llvm.org/svn/llvm-project/clang-tools-extra/branches/release_50/
> > extra
> > cd ../../../projects
> > svn co
> > http://llvm.org/svn/llvm-project/compiler-rt/branches/release_50
> > compiler-rt
> > svn co http://llvm.org/svn/llvm-project/openmp/branches/release_50
> > openmp
> > svn co https://github.com/clang-ykt/openmp libomptarget
> >
> >
> > mkdir build
> > cd build
> > cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr/local/${LLVM_VERSION} \
> > -GNinja \
> > -DLLVM_TARGETS_TO_BUILD:STRING="NVPTX;X86" \
> > -DCMAKE_BUILD_TYPE:STRING="Release" \
> > -DLLVM_PARALLEL_COMPILE_JOBS:STRING="4" \
> > -DLLVM_PARALLEL_LINK_JOBS:STRING="4" \
> > -DCMAKE_C_COMPILER:STRING="${DIRPREFIX_PROG}/${GCCDIR}/bin/gcc" \
> > -DCMAKE_C_FLAGS:STRING="-m64 -I/usr/local/valgrind/include" \
> > -DCMAKE_CXX_COMPILER:STRING="${DIRPREFIX_PROG}/${GCCDIR}/bin/g++" \
> > -DCMAKE_CXX_FLAGS:STRING="-m64 -I/usr/local/valgrind/include" \
> > -DCMAKE_EXE_LINKER_FLAGS:STRING="-m64" \
> > -DLLVM_LIBDIR_SUFFIX:STRING="64" \
> > -DLLVM_POLLY_LINK_INTO_TOOLS:BOOL=ON \
> >
> > -DLIBOMPTARGET_DEP_LIBELF_INCLUDE_DIR:STRING="/usr/
> local/elfutils-0.169/include"
> > \
> >
> > -DLIBOMPTARGET_DEP_LIBELF_LIBRARIES:STRING="/usr/local/
> elfutils-0.169/lib64/libelf.so"
> > \
> > -DLIBOMPTARGET_DEP_LIBFFI_INCLUDE_DIR:STRING="/usr/include" \
> > -DLIBOMPTARGET_DEP_LIBFFI_LIBRARIES:STRING="/usr/lib64/libffi.so" \
> > -DCUDA_INCLUDE_DIRS:STRING="/usr/local/cuda/include" \
> > -DCUDA_LIBRARIES:STRING="/usr/local/cuda/lib64/libcudart.so" \
> > -DBUILD_SHARED_LIBS:BOOL=ON \
> > ../llvm \
> > |& tee log.cmake
> >
> > ninja |& tee log.ninja-build
> > ninja check |& tee log.ninja-check
> > ninja install |& tee log.ninja-install
> >
> > loki build 217 tail -11 log.cmake
> > Manually-specified variables were not used by the project:
> > CUDA_INCLUDE_DIRS
> > CUDA_LIBRARIES
> > LIBOMPTARGET_DEP_LIBELF_INCLUDE_DIR
> > LIBOMPTARGET_DEP_LIBELF_LIBRARIES
> > LIBOMPTARGET_DEP_LIBFFI_INCLUDE_DIR
> > LIBOMPTARGET_DEP_LIBFFI_LIBRARIES
> > -- Build files have been written to: /export2/src/llvm-5.0/build
> >
> > loki build 218 grep -i omptarget log.*
> > log.cmake: LIBOMPTARGET_DEP_LIBELF_INCLUDE_DIR
> > log.cmake: LIBOMPTARGET_DEP_LIBELF_LIBRARIES
> > log.cmake: LIBOMPTARGET_DEP_LIBFFI_INCLUDE_DIR
> > log.cmake: LIBOMPTARGET_DEP_LIBFFI_LIBRARIES
> > loki build 219
> >
> >
> > Isn't libomptarget supported any longer? Do I have to change something
> > in
> > my checkout or configuration? I would be grateful if somebody can
> > answer
> > my questions. Please let me know if you need anything else. Thank you
> > very
> > much for any help in advance.
> >
> >
> > Kind regards
> >
> > Siegmar
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 10 Aug 2017 12:01:55 +0100
> From: Nuno Lopes via llvm-dev <llvm-dev at lists.llvm.org>
> To: "Nema, Ashutosh" <Ashutosh.Nema at amd.com>, "llvm-dev"
> <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] InstCombine GEP
> Message-ID: <EBC09CB892C8466D8845FA6ACB695E09 at PC07655>
> Content-Type: text/plain; charset="utf-8"
>
> I agree that’s a bit strange.
> I dunno about SROA, but BasicAA certainly knows about structs and unions.
> I don’t think right now it has any problem handling those. (and if there’s
> some case it doesn’t, shouldn’t be hard to fix)
> Also, BasicAA has special rules for arrays of structs that can conclude
> no-alias even if some of the indexes aren’t constants. So you could even
> turn those no-alias results into may-alias; instcombine is losing
> information here.
>
> I guess you could lookup the history to see why/when that transformation
> was introduced if noone remembers.
>
> Nuno
>
>
>
> From: Nema, Ashutosh via llvm-dev
> Sent: Thursday, August 10, 2017 8:22 AM
> To: llvm-dev
> Subject: [llvm-dev] InstCombine GEP
>
> Hi,
>
>
>
> I have a doubt with GEP transformation in the instruction-combiner.
>
>
>
> Consider below test-case:
>
> struct ABC {
>
> int A;
>
> int B[100];
>
> struct XYZ {
>
> int X;
>
> int Y[100];
>
> } OBJ;
>
> };
>
> void Setup(struct ABC *);
>
> int foo(int offset) {
>
> struct ABC *Ptr = malloc(sizeof(struct ABC));
>
> Setup(Ptr);
>
> return Ptr->OBJ.X + Ptr->OBJ.Y[33];
>
> }
>
>
>
> Generated IR for the test-case:
>
> define i32 @foo(i32 %offset) local_unnamed_addr #0 {
>
> entry:
>
> %call = tail call i8* @malloc(i64 808)
>
> %0 = bitcast i8* %call to %struct.ABC*
>
> tail call void @Setup(%struct.ABC* %0) #3
>
> %OBJ = getelementptr inbounds i8, i8* %call, i64 404
>
> %X = bitcast i8* %OBJ to i32*
>
> %1 = load i32, i32* %X, align 4, !tbaa !2
>
> %arrayidx = getelementptr inbounds i8, i8* %call, i64 540
>
> %2 = bitcast i8* %arrayidx to i32*
>
> %3 = load i32, i32* %2, align 4, !tbaa !8
>
> %add = add nsw i32 %3, %1
>
> ret i32 %add
>
> }
>
>
>
> Instruction combiner transforms GEPs to i8 type, because of this the GEP
> offset looks weird and the actual type information is missing on GEP.
>
> I expected the GEPs to use the actual type offsetting for which the memory
> is allocated.
>
>
>
> Expected IR:
>
>
>
> ; Function Attrs: nounwind uwtable
>
> define i32 @foo(i32 %offset) local_unnamed_addr #0 {
>
> entry:
>
> %call = tail call i8* @malloc(i64 808)
>
> %0 = bitcast i8* %call to %struct.ABC*
>
> tail call void @Setup(%struct.ABC* %0) #3
>
> %X = getelementptr inbounds %struct.ABC, %struct.ABC* %0, i64 0, i32 2,
> i32 0
>
> %1 = load i32, i32* %X, align 4, !tbaa !2
>
> %arrayidx = getelementptr inbounds %struct.ABC, %struct.ABC* %0, i64 0,
> i32 2, i32 1, i64 33
>
> %2 = load i32, i32* %arrayidx, align 4, !tbaa !8
>
> %add = add nsw i32 %2, %1
>
> ret i32 %add
>
> }
>
>
>
> In the above IR the GEP offsetting looks very explicit for the type
> struct.ABC.
>
>
>
> Looking at the InstCombiner source found the below code is responsible for
> it:
>
> 1914 /// See if we can simplify:
>
> 1915 /// X = bitcast A* to B*
>
> 1916 /// Y = gep X, <...constant indices...>
>
> 1917 /// into a gep of the original struct. This is important for SROA
> and alias
>
> 1918 /// analysis of unions. If "A" is also a bitcast, wait for A/X to
> be merged.
>
> 1919 if (BitCastInst *BCI = dyn_cast<BitCastInst>(PtrOp)) {
>
> 1920 ....
>
>
>
> I’m not sure how transforming GEP offset to i8 type will help alias
> analysis & SROA for the mentioned test case.
>
>
>
> Regards,
>
> Ashutosh
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/llvm-dev/
> attachments/20170810/28bf3864/attachment-0001.html>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 10 Aug 2017 11:24:15 -0400
> From: Charles Saternos via llvm-dev <llvm-dev at lists.llvm.org>
> To: Davide Italiano <davide at freebsd.org>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] [ThinLTO] Suggestions on how to traverse SCCs
> in the Module Summary Index bottom up
> Message-ID:
> <CAFC5sR1Fi3=42K=7L1SiDa5RO0rcvXkFyvvtKbNF6qViN0rKGQ at mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> >
> > That said, I'm not sure why you need to find the entry point of the
> > program.
> > SCCs (collapsed) create a DAG so you can first propagate the attribute
> > within the SCC (until convergence) and then propagate across SCCs (see
> > the strong component section of
> > http://www.imm.dtu.dk/~hrni/PPA/slides6.pdf ). Unless I misunderstood
> > your problem (which I might have :),
>
>
> OK cool, the slideshow clarified what SCCs do. So it looks like
> scc_iterator will navigate the reduced graph in topological order, which
> means all I have to worry about are describing the graphtraits, and the
> scc_iterator does the rest?
>
> you don't need to start from the entry point, as long as you have a
> > topological order.
>
>
> That makes sense. I was going off the implementation of the callgraph
> (which starts at the callgraph's entry point), but I was misinterpreting
> the significance of that. It looks like my problem is just a bug in my
> GraphTraits implementation then, because I'm only finding 2 SCCs (each with
> one node) in my test example which should be finding 10 nodes.
>
> Thanks for the help Davide!
> - Charles
>
> On Thu, Aug 10, 2017 at 3:39 AM, Davide Italiano <davide at freebsd.org>
> wrote:
>
> > On Wed, Aug 9, 2017 at 3:04 PM, Charles Saternos via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> > > I just realized that I've been misunderstanding this (I think). If I'm
> > > understanding it now, the entry node for the graph should actually be
> the
> > > graph's root (not a bottom node), and that the scc_iterator works its
> way
> > > down. So for the ModuleSummary, I should find the main function and
> > return
> > > that (or whatever function is the entry point for the entire program).
> > >
> >
> > You can look at how the traits are used. Several passes in tree use
> > them, so you can get an idea (look for CGSCC, for example, the
> > inliner). Also, SCCs are discovered in post-order. If you want a
> > different visitation order you should built that yourself on top of
> > the existing one (see for example the code in FunctionAttrs.cpp which
> > discovers the SCC in RPO).
> >
> > That said, I'm not sure why you need to find the entry point of the
> > program.
> > SCCs (collapsed) create a DAG so you can first propagate the attribute
> > within the SCC (until convergence) and then propagate across SCCs (see
> > the strong component section of
> > http://www.imm.dtu.dk/~hrni/PPA/slides6.pdf ). Unless I misunderstood
> > your problem (which I might have :), you don't need to start from the
> > entry point, as long as you have a topological order.
> >
> > --
> > Davide
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/llvm-dev/
> attachments/20170810/d58f75cc/attachment-0001.html>
>
> ------------------------------
>
> Message: 9
> Date: Thu, 10 Aug 2017 08:33:44 -0700
> From: Rafael Avila de Espindola via llvm-dev <llvm-dev at lists.llvm.org>
> To: Chris Lattner <clattner at llvm.org>, llvm-dev
> <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] Relicensing: Revised Developer Policy
> Message-ID:
> <87wp6b8mjr.fsf at dell.i-did-not-set--mail-host-address--
> so-tickle-me>
> Content-Type: text/plain; charset=utf-8
>
> Hi,
>
> I still don't see any justification in the text why a license change is
> required over having a contributor agreement including whatever patent
> wording we want.
>
> As such, I don't agree with it.
>
> Cheers,
> Rafael
>
> Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
> > Hi all,
> >
> > Now that we’ve settled on the license legalese to get to, we need to
> start the process of relicensing. We’re still sorting through all of the
> details of what this will take, but the first step is clear: new
> contributions to LLVM will need to be under both the old license structure
> and the new one (until the old structure is completely phased out). From a
> mechanical perspective, this is pretty simple, but I want to make sure that
> the community is aware of this and has time to digest and discuss any
> concerns.
> >
> > In order to spell out what this will look like, we’ve gone ahead and
> revised http://llvm.org/docs/DeveloperPolicy.html to reflect what the new
> structure will look like. While the license text is the canonical truth,
> the DeveloperPolicy serves a few purposes: it explains to non-lawyers what
> the license means, provides rationale for the design, and deals with
> relicensing process topics.
> >
> > I’ve attached a draft of the revised document below. Please take a look
> and let me know if anything should be further clarified or if you have any
> other questions and comments. Thanks!
> >
> > -Chris
> >
> >
> >
> >
> >
> > Copyright, License, and Patents
> > ===============================
> >
> > .. note::
> >
> > This section deals with legal matters but does not provide legal
> advice. We
> > are not lawyers --- please seek legal counsel from a licensed
> attorney.
> >
> > This section addresses the issues of copyright, license and patents for
> the LLVM
> > project. The copyright for the code is held by the contributors of
> > the code. The code is licensed under permissive `open source licensing
> terms`_,
> > namely the Apache 2 license, which includes a copyright and `patent
> license`_.
> > When you contribute code to the LLVM project, you license it under these
> terms.
> >
> > If you have questions or comments about these topics, please contact the
> > `LLVM Developer's Mailing List <mailto:llvm-dev at lists.llvm.org>`_.
> However,
> > please realize that most compiler developers are not lawyers, and
> therefore you
> > will not be getting official legal advice.
> >
> > Copyright
> > ---------
> >
> > The LLVM project does not collect copyright assignments, which means
> that the
> > copyright for the code in the project is held by the respective
> contributors.
> > Because you (or your company)
> > retain ownership of the code you contribute, you know it may only be
> used under
> > the terms of the open source license you contributed it under: the
> license for
> > your contributions cannot be changed in the future without your approval.
> >
> > Because the LLVM project does not require copyright assignments,
> changing the
> > LLVM license requires tracking down the
> > contributors to LLVM and getting them to agree that a license change is
> > acceptable for their contributions. We feel that a high burden for
> relicensing
> > is good for the project, because contributors do not have to fear that
> their
> > code will be used in a way with which they disagree.
> >
> > Relicensing
> > -----------
> >
> > The last paragraph notwithstanding, the LLVM Project is in the middle of
> a large
> > effort to change licenses, which aims to solve several problems:
> >
> > * The old licenses made it difficult to move code from (e.g.) the
> compiler to
> > runtime libraries, because runtime libraries used a different license
> from the
> > rest of the compiler.
> > * Some contributions were not submitted to LLVM due to concerns that
> > the patent grant required by the project was overly broad.
> > * The patent grant was unique to the LLVM Project, not written by a
> lawyer, and
> > was difficult to determine what was protection was provided (if any).
> >
> > The scope of relicensing is all code that is considered part of the LLVM
> > project, including the main LLVM repository, runtime libraries
> (compiler_rt,
> > OpenMP, etc), Polly, and all other subprojects. There are a few
> exceptions:
> >
> > * Code imported from other projects (e.g. Google Test, Autoconf, etc)
> will
> > remain as it is. This code isn't *developed* as part of the LLVM
> project, it
> > is *used* by LLVM.
> > * Some subprojects are impractical or uninteresting to relicense (e.g.
> llvm-gcc
> > and dragonegg). These will be split off from the LLVM project (e.g. to
> > separate Github projects), allowing interested people to continue their
> > development elsewhere.
> >
> > To relicense LLVM, we will be seeking approval from all of the copyright
> holders
> > of code in the repository, or potentially remove/rewrite code if we
> cannot.
> > This is a large
> > and challenging project which will take a significant amount of time to
> > complete. In the interim, **all contributions to the project will be
> made under
> > the terms of both the new license and the legacy license scheme** (each
> of which
> > is described below). The exception to this is the legacy patent grant,
> which
> > will not be required for new contributions.
> >
> > When all of the code in the project has been converted to the new
> license or
> > removed, we will drop the requirement to contribute under the legacy
> license.
> > This will achieve the goal of having
> > a single standardized license for the entire codebase.
> >
> > If you are a prior contributor to LLVM and have not done so already,
> please do
> > *TODO* to allow us to use your code. *Add a link to a separate page
> here, which
> > is probably a click through web form or something like that. Details to
> be
> > determined later*.
> >
> >
> > .. _open source licensing terms:
> >
> > New LLVM Project License Framework
> > ----------------------------------
> >
> > Contributions to LLVM are licensed under the `Apache License, Version 2.0
> > <https://www.apache.org/licenses/LICENSE-2.0>`_, with two limited
> > exceptions intended to ensure that LLVM is very permissively licensed.
> > Collectively, the name of this license is "Apache 2.0 License with LLVM
> > exceptions". The exceptions read:
> >
> > ::
> >
> > ---- LLVM Exceptions to the Apache 2.0 License ----
> >
> > As an exception, if, as a result of your compiling your source code,
> portions
> > of this Software are embedded into an Object form of such source
> code, you
> > may redistribute such embedded portions in such Object form without
> complying
> > with the conditions of Sections 4(a), 4(b) and 4(d) of the License.
> >
> > In addition, if you combine or link compiled forms of this Software
> with
> > software that is licensed under the GPLv2 ("Combined Software") and
> if a
> > court of competent jurisdiction determines that the patent provision
> (Section
> > 3), the indemnity provision (Section 9) or other Section of the
> License
> > conflicts with the conditions of the GPLv2, you may retroactively and
> > prospectively choose to deem waived or otherwise exclude such
> Section(s) of
> > the License, but only in their entirety and only with respect to the
> Combined
> > Software.
> >
> >
> > We intend to keep LLVM perpetually open source and available under a
> permissive
> > license - this fosters the widest adoption of LLVM by
> > **allowing commercial products to be derived from LLVM** with few
> restrictions
> > and without a requirement for making any derived works also open
> source. In
> > particular, LLVM's license is not a "copyleft" license like the GPL.
> >
> > The "Apache 2.0 License with LLVM exceptions" allows you to:
> >
> > * freely download and use LLVM (in whole or in part) for personal,
> internal, or
> > commercial purposes.
> > * include LLVM in packages or distributions you create.
> > * combine LLVM with code licensed under every other major open source
> > license (including BSD, MIT, GPLv2, GPLv3...).
> > * make changes to LLVM code without being required to contribute it back
> > to the project - contributions are appreciated though!
> >
> > However, it imposes these limitations on you:
> >
> > * You must retain the copyright notice if you redistribute LLVM: You
> cannot
> > strip the copyright headers off or replace them with your own.
> > * Binaries that include LLVM must reproduce the copyright notice (e.g.
> in an
> > included README file or in an "About" box), unless the LLVM code was
> added as
> > a by-product of compilation. For example, if an LLVM runtime library
> like
> > compiler_rt or libc++ was automatically included into your application
> by the
> > compiler, you do not need to attribute it.
> > * You can't use our names to promote your products (LLVM derived or not)
> -
> > though you can make truthful statements about your use of the LLVM
> code,
> > without implying our sponsorship.
> > * There's no warranty on LLVM at all.
> >
> > We want LLVM code to be widely used, and believe that this provides a
> model that
> > is great for contributors and users of the project. For more
> information about
> > the Apache 2.0 License, please see the `Apache License FAQ
> > <http://www.apache.org/foundation/license-faq.html>`_, maintained by the
> > Apache Project.
> >
> >
> > .. note::
> >
> > The LLVM Project includes some really old subprojects (dragonegg,
> > llvm-gcc-4.0, and llvm-gcc-4.2), which are licensed under **GPL
> > licenses**. This code is not actively maintained - it does not even
> > build successfully. This code is cleanly separated into distinct SVN
> > repositories from the rest of LLVM, and the LICENSE.txt files
> specifically
> > indicate that they contain GPL code. When LLVM transitions from SVN
> to Git,
> > we plan to drop these code bases from the new repository structure.
> >
> >
> > .. _patent license:
> >
> > Patents
> > -------
> >
> > Section 3 of the Apache 2.0 license is a patent grant under which
> > contributors of code to the project contribute the rights to use any of
> > their patents that would otherwise be infringed by that code contribution
> > (protecting uses of that code). Further, the patent grant is revoked
> > from anyone who files a patent lawsuit about code in LLVM - this
> protects the
> > community by providing a "patent commons" for the code base and reducing
> the
> > odds of patent lawsuits in general.
> >
> > The license specifically scopes which patents are included with code
> > contributions. To help explain this, the `Apache License FAQ
> > <http://www.apache.org/foundation/license-faq.html>`_ explains this
> scope using
> > some questions and answers, which we reproduce here for your convenience
> (for
> > reference, the "ASF" is the Apache Software Foundation, the guidance
> still
> > holds though)::
> >
> > Q1: If I own a patent and contribute to a Work, and, at the time my
> > contribution is included in that Work, none of my patent's claims are
> subject
> > to Apache's Grant of Patent License, is there a way any of those
> claims would
> > later become subject to the Grant of Patent License solely due to
> subsequent
> > contributions by other parties who are not licensees of that patent.
> >
> > A1: No.
> >
> > Q2: If at any time after my contribution, I am able to license other
> patent
> > claims that would have been subject to Apache's Grant of Patent
> License if
> > they were licenseable by me at the time of my contribution, do those
> other
> > claims become subject to the Grant of Patent License?
> >
> > A2: Yes.
> >
> > Q3: If I own or control a licensable patent and contribute code to a
> specific
> > Apache product, which of my patent claims are subject to Apache's
> Grant of
> > Patent License?
> >
> > A3: The only patent claims that are licensed to the ASF are those
> you own or
> > have the right to license that read on your contribution or on the
> > combination of your contribution with the specific Apache product to
> which
> > you contributed as it existed at the time of your contribution. No
> additional
> > patent claims become licensed as a result of subsequent combinations
> of your
> > contribution with any other software. Note, however, that licensable
> patent
> > claims include those that you acquire in the future, as long as they
> read on
> > your original contribution as made at the original time. Once a
> patent claim
> > is subject to Apache's Grant of Patent License, it is licensed under
> the
> > terms of that Grant to the ASF and to recipients of any software
> distributed
> > by the ASF for any Apache software product whatsoever.
> >
> >
> > Legacy License Structure
> > ------------------------
> >
> > .. note::
> > The code base was previously licensed under the Terms described here.
> > We are in the middle of relicensing to a new approach (described
> above), but
> > until this effort is complete, the code is also still available under
> these
> > terms. Once we finish the relicensing project, new versions of the
> code will
> > not be available under these terms. However, nothing takes away your
> right
> > to use old versions under the licensing terms under which they were
> > originally released.
> >
> > We intend to keep LLVM perpetually open source and to use a permissive
> open
> > source license. The code in
> > LLVM is available under the `University of Illinois/NCSA Open Source
> License
> > <http://www.opensource.org/licenses/UoI-NCSA.php>`_, which boils down to
> > this:
> >
> > * You can freely distribute LLVM.
> > * You must retain the copyright notice if you redistribute LLVM.
> > * Binaries derived from LLVM must reproduce the copyright notice (e.g.
> in an
> > included README file).
> > * You can't use our names to promote your LLVM derived products.
> > * There's no warranty on LLVM at all.
> >
> > We believe this fosters the widest adoption of LLVM because it **allows
> > commercial products to be derived from LLVM** with few restrictions and
> without
> > a requirement for making any derived works also open source (i.e. LLVM's
> > license is not a "copyleft" license like the GPL). We suggest that you
> read the
> > `License <http://www.opensource.org/licenses/UoI-NCSA.php>`_ if further
> > clarification is needed.
> >
> > In addition to the UIUC license, the runtime library components of LLVM
> > (**compiler_rt, libc++, and libclc**) are also licensed under the `MIT
> License
> > <http://www.opensource.org/licenses/mit-license.php>`_, which does not
> contain
> > the binary redistribution clause. As a user of these runtime libraries,
> it
> > means that you can choose to use the code under either license (and thus
> don't
> > need the binary redistribution clause), and as a contributor to the code
> that
> > you agree that any contributions to these libraries be licensed under
> both
> > licenses. We feel that this is important for runtime libraries, because
> they
> > are implicitly linked into applications and therefore should not subject
> those
> > applications to the binary redistribution clause. This also means that
> it is ok
> > to move code from (e.g.) libc++ to the LLVM core without concern, but
> that code
> > cannot be moved from the LLVM core to libc++ without the copyright
> owner's
> > permission.
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> ------------------------------
>
> Message: 10
> Date: Thu, 10 Aug 2017 08:53:06 -0700
> From: Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org>
> To: Rafael Avila de Espindola <rafael.espindola at gmail.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] Relicensing: Revised Developer Policy
> Message-ID: <20A56370-75A6-4FA0-B2A5-9F3F593CBD7B at llvm.org>
> Content-Type: text/plain; charset=utf-8
>
> Hi Rafael,
>
> We’ve discussed why a license change is preferable over the span of
> several years now. I’m happy to explain over the phone, contact me off
> list and we can talk.
>
> -Chris
>
> > On Aug 10, 2017, at 8:33 AM, Rafael Avila de Espindola <
> rafael.espindola at gmail.com> wrote:
> >
> > Hi,
> >
> > I still don't see any justification in the text why a license change is
> > required over having a contributor agreement including whatever patent
> > wording we want.
> >
> > As such, I don't agree with it.
> >
> > Cheers,
> > Rafael
> >
> > Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> writes:
> >
> >> Hi all,
> >>
> >> Now that we’ve settled on the license legalese to get to, we need to
> start the process of relicensing. We’re still sorting through all of the
> details of what this will take, but the first step is clear: new
> contributions to LLVM will need to be under both the old license structure
> and the new one (until the old structure is completely phased out). From a
> mechanical perspective, this is pretty simple, but I want to make sure that
> the community is aware of this and has time to digest and discuss any
> concerns.
> >>
> >> In order to spell out what this will look like, we’ve gone ahead and
> revised http://llvm.org/docs/DeveloperPolicy.html to reflect what the new
> structure will look like. While the license text is the canonical truth,
> the DeveloperPolicy serves a few purposes: it explains to non-lawyers what
> the license means, provides rationale for the design, and deals with
> relicensing process topics.
> >>
> >> I’ve attached a draft of the revised document below. Please take a
> look and let me know if anything should be further clarified or if you have
> any other questions and comments. Thanks!
> >>
> >> -Chris
> >>
> >>
> >>
> >>
> >>
> >> Copyright, License, and Patents
> >> ===============================
> >>
> >> .. note::
> >>
> >> This section deals with legal matters but does not provide legal
> advice. We
> >> are not lawyers --- please seek legal counsel from a licensed
> attorney.
> >>
> >> This section addresses the issues of copyright, license and patents for
> the LLVM
> >> project. The copyright for the code is held by the contributors of
> >> the code. The code is licensed under permissive `open source licensing
> terms`_,
> >> namely the Apache 2 license, which includes a copyright and `patent
> license`_.
> >> When you contribute code to the LLVM project, you license it under
> these terms.
> >>
> >> If you have questions or comments about these topics, please contact the
> >> `LLVM Developer's Mailing List <mailto:llvm-dev at lists.llvm.org>`_.
> However,
> >> please realize that most compiler developers are not lawyers, and
> therefore you
> >> will not be getting official legal advice.
> >>
> >> Copyright
> >> ---------
> >>
> >> The LLVM project does not collect copyright assignments, which means
> that the
> >> copyright for the code in the project is held by the respective
> contributors.
> >> Because you (or your company)
> >> retain ownership of the code you contribute, you know it may only be
> used under
> >> the terms of the open source license you contributed it under: the
> license for
> >> your contributions cannot be changed in the future without your
> approval.
> >>
> >> Because the LLVM project does not require copyright assignments,
> changing the
> >> LLVM license requires tracking down the
> >> contributors to LLVM and getting them to agree that a license change is
> >> acceptable for their contributions. We feel that a high burden for
> relicensing
> >> is good for the project, because contributors do not have to fear that
> their
> >> code will be used in a way with which they disagree.
> >>
> >> Relicensing
> >> -----------
> >>
> >> The last paragraph notwithstanding, the LLVM Project is in the middle
> of a large
> >> effort to change licenses, which aims to solve several problems:
> >>
> >> * The old licenses made it difficult to move code from (e.g.) the
> compiler to
> >> runtime libraries, because runtime libraries used a different license
> from the
> >> rest of the compiler.
> >> * Some contributions were not submitted to LLVM due to concerns that
> >> the patent grant required by the project was overly broad.
> >> * The patent grant was unique to the LLVM Project, not written by a
> lawyer, and
> >> was difficult to determine what was protection was provided (if any).
> >>
> >> The scope of relicensing is all code that is considered part of the LLVM
> >> project, including the main LLVM repository, runtime libraries
> (compiler_rt,
> >> OpenMP, etc), Polly, and all other subprojects. There are a few
> exceptions:
> >>
> >> * Code imported from other projects (e.g. Google Test, Autoconf, etc)
> will
> >> remain as it is. This code isn't *developed* as part of the LLVM
> project, it
> >> is *used* by LLVM.
> >> * Some subprojects are impractical or uninteresting to relicense (e.g.
> llvm-gcc
> >> and dragonegg). These will be split off from the LLVM project (e.g. to
> >> separate Github projects), allowing interested people to continue their
> >> development elsewhere.
> >>
> >> To relicense LLVM, we will be seeking approval from all of the
> copyright holders
> >> of code in the repository, or potentially remove/rewrite code if we
> cannot.
> >> This is a large
> >> and challenging project which will take a significant amount of time to
> >> complete. In the interim, **all contributions to the project will be
> made under
> >> the terms of both the new license and the legacy license scheme** (each
> of which
> >> is described below). The exception to this is the legacy patent grant,
> which
> >> will not be required for new contributions.
> >>
> >> When all of the code in the project has been converted to the new
> license or
> >> removed, we will drop the requirement to contribute under the legacy
> license.
> >> This will achieve the goal of having
> >> a single standardized license for the entire codebase.
> >>
> >> If you are a prior contributor to LLVM and have not done so already,
> please do
> >> *TODO* to allow us to use your code. *Add a link to a separate page
> here, which
> >> is probably a click through web form or something like that. Details
> to be
> >> determined later*.
> >>
> >>
> >> .. _open source licensing terms:
> >>
> >> New LLVM Project License Framework
> >> ----------------------------------
> >>
> >> Contributions to LLVM are licensed under the `Apache License, Version
> 2.0
> >> <https://www.apache.org/licenses/LICENSE-2.0>`_, with two limited
> >> exceptions intended to ensure that LLVM is very permissively licensed.
> >> Collectively, the name of this license is "Apache 2.0 License with LLVM
> >> exceptions". The exceptions read:
> >>
> >> ::
> >>
> >> ---- LLVM Exceptions to the Apache 2.0 License ----
> >>
> >> As an exception, if, as a result of your compiling your source code,
> portions
> >> of this Software are embedded into an Object form of such source
> code, you
> >> may redistribute such embedded portions in such Object form without
> complying
> >> with the conditions of Sections 4(a), 4(b) and 4(d) of the License.
> >>
> >> In addition, if you combine or link compiled forms of this Software
> with
> >> software that is licensed under the GPLv2 ("Combined Software") and
> if a
> >> court of competent jurisdiction determines that the patent provision
> (Section
> >> 3), the indemnity provision (Section 9) or other Section of the
> License
> >> conflicts with the conditions of the GPLv2, you may retroactively and
> >> prospectively choose to deem waived or otherwise exclude such
> Section(s) of
> >> the License, but only in their entirety and only with respect to the
> Combined
> >> Software.
> >>
> >>
> >> We intend to keep LLVM perpetually open source and available under a
> permissive
> >> license - this fosters the widest adoption of LLVM by
> >> **allowing commercial products to be derived from LLVM** with few
> restrictions
> >> and without a requirement for making any derived works also open
> source. In
> >> particular, LLVM's license is not a "copyleft" license like the GPL.
> >>
> >> The "Apache 2.0 License with LLVM exceptions" allows you to:
> >>
> >> * freely download and use LLVM (in whole or in part) for personal,
> internal, or
> >> commercial purposes.
> >> * include LLVM in packages or distributions you create.
> >> * combine LLVM with code licensed under every other major open source
> >> license (including BSD, MIT, GPLv2, GPLv3...).
> >> * make changes to LLVM code without being required to contribute it back
> >> to the project - contributions are appreciated though!
> >>
> >> However, it imposes these limitations on you:
> >>
> >> * You must retain the copyright notice if you redistribute LLVM: You
> cannot
> >> strip the copyright headers off or replace them with your own.
> >> * Binaries that include LLVM must reproduce the copyright notice (e.g.
> in an
> >> included README file or in an "About" box), unless the LLVM code was
> added as
> >> a by-product of compilation. For example, if an LLVM runtime library
> like
> >> compiler_rt or libc++ was automatically included into your application
> by the
> >> compiler, you do not need to attribute it.
> >> * You can't use our names to promote your products (LLVM derived or
> not) -
> >> though you can make truthful statements about your use of the LLVM
> code,
> >> without implying our sponsorship.
> >> * There's no warranty on LLVM at all.
> >>
> >> We want LLVM code to be widely used, and believe that this provides a
> model that
> >> is great for contributors and users of the project. For more
> information about
> >> the Apache 2.0 License, please see the `Apache License FAQ
> >> <http://www.apache.org/foundation/license-faq.html>`_, maintained by
> the
> >> Apache Project.
> >>
> >>
> >> .. note::
> >>
> >> The LLVM Project includes some really old subprojects (dragonegg,
> >> llvm-gcc-4.0, and llvm-gcc-4.2), which are licensed under **GPL
> >> licenses**. This code is not actively maintained - it does not even
> >> build successfully. This code is cleanly separated into distinct SVN
> >> repositories from the rest of LLVM, and the LICENSE.txt files
> specifically
> >> indicate that they contain GPL code. When LLVM transitions from SVN
> to Git,
> >> we plan to drop these code bases from the new repository structure.
> >>
> >>
> >> .. _patent license:
> >>
> >> Patents
> >> -------
> >>
> >> Section 3 of the Apache 2.0 license is a patent grant under which
> >> contributors of code to the project contribute the rights to use any of
> >> their patents that would otherwise be infringed by that code
> contribution
> >> (protecting uses of that code). Further, the patent grant is revoked
> >> from anyone who files a patent lawsuit about code in LLVM - this
> protects the
> >> community by providing a "patent commons" for the code base and
> reducing the
> >> odds of patent lawsuits in general.
> >>
> >> The license specifically scopes which patents are included with code
> >> contributions. To help explain this, the `Apache License FAQ
> >> <http://www.apache.org/foundation/license-faq.html>`_ explains this
> scope using
> >> some questions and answers, which we reproduce here for your
> convenience (for
> >> reference, the "ASF" is the Apache Software Foundation, the guidance
> still
> >> holds though)::
> >>
> >> Q1: If I own a patent and contribute to a Work, and, at the time my
> >> contribution is included in that Work, none of my patent's claims are
> subject
> >> to Apache's Grant of Patent License, is there a way any of those
> claims would
> >> later become subject to the Grant of Patent License solely due to
> subsequent
> >> contributions by other parties who are not licensees of that patent.
> >>
> >> A1: No.
> >>
> >> Q2: If at any time after my contribution, I am able to license other
> patent
> >> claims that would have been subject to Apache's Grant of Patent
> License if
> >> they were licenseable by me at the time of my contribution, do those
> other
> >> claims become subject to the Grant of Patent License?
> >>
> >> A2: Yes.
> >>
> >> Q3: If I own or control a licensable patent and contribute code to a
> specific
> >> Apache product, which of my patent claims are subject to Apache's
> Grant of
> >> Patent License?
> >>
> >> A3: The only patent claims that are licensed to the ASF are those
> you own or
> >> have the right to license that read on your contribution or on the
> >> combination of your contribution with the specific Apache product to
> which
> >> you contributed as it existed at the time of your contribution. No
> additional
> >> patent claims become licensed as a result of subsequent combinations
> of your
> >> contribution with any other software. Note, however, that licensable
> patent
> >> claims include those that you acquire in the future, as long as they
> read on
> >> your original contribution as made at the original time. Once a
> patent claim
> >> is subject to Apache's Grant of Patent License, it is licensed under
> the
> >> terms of that Grant to the ASF and to recipients of any software
> distributed
> >> by the ASF for any Apache software product whatsoever.
> >>
> >>
> >> Legacy License Structure
> >> ------------------------
> >>
> >> .. note::
> >> The code base was previously licensed under the Terms described here.
> >> We are in the middle of relicensing to a new approach (described
> above), but
> >> until this effort is complete, the code is also still available under
> these
> >> terms. Once we finish the relicensing project, new versions of the
> code will
> >> not be available under these terms. However, nothing takes away your
> right
> >> to use old versions under the licensing terms under which they were
> >> originally released.
> >>
> >> We intend to keep LLVM perpetually open source and to use a permissive
> open
> >> source license. The code in
> >> LLVM is available under the `University of Illinois/NCSA Open Source
> License
> >> <http://www.opensource.org/licenses/UoI-NCSA.php>`_, which boils down
> to
> >> this:
> >>
> >> * You can freely distribute LLVM.
> >> * You must retain the copyright notice if you redistribute LLVM.
> >> * Binaries derived from LLVM must reproduce the copyright notice (e.g.
> in an
> >> included README file).
> >> * You can't use our names to promote your LLVM derived products.
> >> * There's no warranty on LLVM at all.
> >>
> >> We believe this fosters the widest adoption of LLVM because it **allows
> >> commercial products to be derived from LLVM** with few restrictions and
> without
> >> a requirement for making any derived works also open source (i.e. LLVM's
> >> license is not a "copyleft" license like the GPL). We suggest that you
> read the
> >> `License <http://www.opensource.org/licenses/UoI-NCSA.php>`_ if further
> >> clarification is needed.
> >>
> >> In addition to the UIUC license, the runtime library components of LLVM
> >> (**compiler_rt, libc++, and libclc**) are also licensed under the `MIT
> License
> >> <http://www.opensource.org/licenses/mit-license.php>`_, which does not
> contain
> >> the binary redistribution clause. As a user of these runtime
> libraries, it
> >> means that you can choose to use the code under either license (and
> thus don't
> >> need the binary redistribution clause), and as a contributor to the
> code that
> >> you agree that any contributions to these libraries be licensed under
> both
> >> licenses. We feel that this is important for runtime libraries,
> because they
> >> are implicitly linked into applications and therefore should not
> subject those
> >> applications to the binary redistribution clause. This also means that
> it is ok
> >> to move code from (e.g.) libc++ to the LLVM core without concern, but
> that code
> >> cannot be moved from the LLVM core to libc++ without the copyright
> owner's
> >> permission.
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> llvm-dev mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> ------------------------------
>
> End of llvm-dev Digest, Vol 158, Issue 52
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170810/96c1a794/attachment-0001.html>
More information about the llvm-dev
mailing list