I'm trying to understand how Mips will fit into the official release procedure. There are two Mips compilers: 1) The X86 resident llvm/clang compiler that can generate code for various Mips targets. 2) The Mips resident compiler (on linux or bsd or other) which would generate code primarily for that same host. How does this fit into the release structure? We would like to make sure that the released X86 hosted Clang/LLVM compiler has been tested for all the Mips targets that we support. We would like to produce a Mips hosted LLVM compiler for official LLVM distribution that can at least generate code for that same Mips host and probably all Mips targets but most likely it would be beyond our resources to test that as a cross compiler to various other LLVM targets. I.e. we can't tell if we can generate correct code the Hexagon processor beyond running whatever is in "make check". Should we be building our Mips native compiler so that it only supports the Mips target for example; if that is all we can test? I'm unclear exactly how we fit into this release process given what I have described above. Tia. Reed
cc'ing Bill as Release Manager On Mon, Mar 10, 2014 at 2:53 PM, reed kotler <rkotler at mips.com> wrote:> I'm trying to understand how Mips will fit into the official release > procedure. > > There are two Mips compilers: > 1) The X86 resident llvm/clang compiler that can generate code for various > Mips targets. > 2) The Mips resident compiler (on linux or bsd or other) which would > generate code primarily for that same host. > > > How does this fit into the release structure?Pretty easily. :)> > We would like to make sure that the released X86 hosted Clang/LLVM compiler > has been tested for all the Mips targets that we support. >You guys should do this then on the release branches after it's been cut.> We would like to produce a Mips hosted LLVM compiler for official LLVM > distribution that can at least generate code for that same Mips host and > probably > all Mips targets but most likely it would be beyond our resources to test > that as a cross compiler to various other LLVM > targets. I.e. we can't tell if we can generate correct code the Hexagon > processor beyond running whatever is in "make check". > Should we be building our Mips native compiler so that it only supports the > Mips target for example; if that is all we can test? >You could do that, I'm not sure what the general thing is with binaries. IMO if a target passes make check then it should be ok to leave in the binary. -eric> I'm unclear exactly how we fit into this release process given what I have > described above. > > Tia. > > Reed > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On 03/10/2014 03:37 PM, Eric Christopher wrote:> cc'ing Bill as Release Manager > > On Mon, Mar 10, 2014 at 2:53 PM, reed kotler <rkotler at mips.com> wrote: >> I'm trying to understand how Mips will fit into the official release >> procedure. >> >> There are two Mips compilers: >> 1) The X86 resident llvm/clang compiler that can generate code for various >> Mips targets. >> 2) The Mips resident compiler (on linux or bsd or other) which would >> generate code primarily for that same host. >> >> >> How does this fit into the release structure? > Pretty easily. :) > >> We would like to make sure that the released X86 hosted Clang/LLVM compiler >> has been tested for all the Mips targets that we support. >> > You guys should do this then on the release branches after it's been cut.What is the procedure here ? We give some feedback to the release manager or we provide a build slave for this or what? Is test-release.sh only for the native Mips compiler or do we run that too using the LLVM/Clang x86 linux compiler to produce output for Mips and then run LNT or something?> >> We would like to produce a Mips hosted LLVM compiler for official LLVM >> distribution that can at least generate code for that same Mips host and >> probably >> all Mips targets but most likely it would be beyond our resources to test >> that as a cross compiler to various other LLVM >> targets. I.e. we can't tell if we can generate correct code the Hexagon >> processor beyond running whatever is in "make check". >> Should we be building our Mips native compiler so that it only supports the >> Mips target for example; if that is all we can test? >> > You could do that, I'm not sure what the general thing is with > binaries. IMO if a target passes make check then it should be ok to > leave in the binary. > > -eric > >> I'm unclear exactly how we fit into this release process given what I have >> described above. >> >> Tia. >> >> Reed >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev