release procedure questions

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

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. :slight_smile:

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

cc'ing Bill as Release Manager

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. :slight_smile:

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?

From: llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu]
On Behalf Of Reed Kotler
Sent: 10 March 2014 22:44
To: Eric Christopher; Bill Wendling
Cc: Doug Gilmore; LLVMdev@cs.uiuc.edu
Subject: Re: [LLVMdev] release procedure questions

> cc'ing Bill as Release Manager
>
>> 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. :slight_smile:
>
>> 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.

From: llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu]
On Behalf Of Reed Kotler
Sent: 10 March 2014 22:44
To: Eric Christopher; Bill Wendling
Cc: Doug Gilmore; LLVMdev@cs.uiuc.edu
Subject: Re: [LLVMdev] release procedure questions

> cc'ing Bill as Release Manager
>
>> 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. :slight_smile:
>
>> 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