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
> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Reed Kotler > Sent: 10 March 2014 22:44 > To: Eric Christopher; Bill Wendling > Cc: Doug Gilmore; LLVMdev at cs.uiuc.edu > Subject: Re: [LLVMdev] release procedure questions > > 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?We should provide feedback by reporting all errors and issues on bugzilla. There's more detail at http://llvm.org/docs/ReleaseProcess.html#release-process the 'Bug Reporting Process' section that follows the linked section is also useful.> 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?Both I believe. We would use test-release.sh on a release candidate on both an X86 and a MIPS host to produce a compiler for each. Then we would run the necessary testing ('make check-all', test-suite, etc.) to cover compiling for MIPS on each compiler. We would only publish the compiler for the MIPS host since there's no need to have two compilers for an X86 host on llvm.org, but we would report failures to bugzilla for both.> >> 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 > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Tue, Mar 11, 2014 at 8:30 AM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote:>> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Reed Kotler >> Sent: 10 March 2014 22:44 >> To: Eric Christopher; Bill Wendling >> Cc: Doug Gilmore; LLVMdev at cs.uiuc.edu >> Subject: Re: [LLVMdev] release procedure questions >> >> 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? > > We should provide feedback by reporting all errors and issues on bugzilla. There's more detail at http://llvm.org/docs/ReleaseProcess.html#release-process the 'Bug Reporting Process' section that follows the linked section is also useful. > >> 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? > > Both I believe. We would use test-release.sh on a release candidate on both an X86 and a MIPS host to produce a compiler for each. Then we would run the necessary testing ('make check-all', test-suite, etc.) to cover compiling for MIPS on each compiler. > We would only publish the compiler for the MIPS host since there's no need to have two compilers for an X86 host on llvm.org, but we would report failures to bugzilla for both.Yup! -eric> >> >> 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 >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev