llvm dev - Jun 2015 - [LLVMdev] [RFC] Ideas on improving Compiler-RT CMake

> On 2015-Jun-03, at 12:57, Chris Bieneman <beanz at apple.com> wrote:
> 
> 
>> On Jun 2, 2015, at 6:29 PM, Richard Smith <richard at
metafoo.co.uk> wrote:
>> 
>> On 2 Jun 2015 2:04 pm, "Jonathan Roelofs" <jonathan at
codesourcery.com> wrote:
>> >
>> >
>> >
>> > On 6/2/15 2:38 PM, Duncan P. N. Exon Smith wrote:
>> >>
>> >>
>> >>> On 2015-Jun-01, at 19:47, Chris Bieneman <beanz at
apple.com> wrote:
>> >>>
>> >>>> If we drop support for building compiler-rt with GCC,
this gets even simpler. Compiler-rt is *Clang's* runtime library, after all.
>> >>>
>> >>>
>> >>> I don’t know if it is on the table to drop supporting
compiler-rt with GCC, but that would dramatically simplify things.
>> >>
>> >>
>> >> Weird, I'd assumed building compiler-rt with something
other than
>> >> clang was unsupported.  Maybe I'm missing something, but
shouldn't
>> >> the only supported configuration be building with the
just-built
>> >> clang?
>> >
>> >
>> > The current default for an in-tree build is to build compiler-rt
with whatever compiler is being used to build Clang... sometimes that compiler
is GCC.
>> >
>> > I agree though. We should always use the just-built Clang, and
have that behavior be opt-out (if folks need it), instead of opt-in as it is
now.
>> 
>> What would the build system do for a cross compile of Clang?
>> 
> This is the big question right? If we decide to only support building
compiler-rt with the just-built clang that inherently means that you always have
to build a clang that can run on host, so cross-compiling clang means building
for host first, then the target.
> 
> I don’t think that is the behavior we want.
Why not?
> I suspect the behavior we probably want is to use the just-built clang by
default unless you are cross-compiling, in which case use the host compiler.
This sounds reasonable (and would obviously be a big improvement), but
I'm interested in what the arguments are against the above/below.

Another option that seems superficially reasonable to me:

  - Only support building compiler-RT with the "matching" clang.
  - When cross-compiling clang, only support the same version of clang
    as the host (and use the host compiler).  In other words, when
    cross-compiling, only support a two-stage build, where the first
    stage builds a host clang, and the second stage builds the cross
    clang.
  - When not cross-compiling, always use the just-built clang.
> Whether or not the host compiler needs to be clang, or any version
restrictions we want to apply is a separate issue.

[re-sending my response to Duncan because I didn’t hit reply-all :-)]
> On Jun 3, 2015, at 1:42 PM, Duncan P. N. Exon Smith <dexonsmith at
apple.com> wrote:
> 
>> 
>> On 2015-Jun-03, at 12:57, Chris Bieneman <beanz at apple.com>
wrote:
>> 
>> 
>>> On Jun 2, 2015, at 6:29 PM, Richard Smith <richard at
metafoo.co.uk> wrote:
>>> 
>>> On 2 Jun 2015 2:04 pm, "Jonathan Roelofs" <jonathan at
codesourcery.com> wrote:
>>>> 
>>>> 
>>>> 
>>>> On 6/2/15 2:38 PM, Duncan P. N. Exon Smith wrote:
>>>>> 
>>>>> 
>>>>>> On 2015-Jun-01, at 19:47, Chris Bieneman <beanz at
apple.com> wrote:
>>>>>> 
>>>>>>> If we drop support for building compiler-rt with
GCC, this gets even simpler. Compiler-rt is *Clang's* runtime library, after
all.
>>>>>> 
>>>>>> 
>>>>>> I don’t know if it is on the table to drop supporting
compiler-rt with GCC, but that would dramatically simplify things.
>>>>> 
>>>>> 
>>>>> Weird, I'd assumed building compiler-rt with something
other than
>>>>> clang was unsupported.  Maybe I'm missing something,
but shouldn't
>>>>> the only supported configuration be building with the
just-built
>>>>> clang?
>>>> 
>>>> 
>>>> The current default for an in-tree build is to build
compiler-rt with whatever compiler is being used to build Clang... sometimes
that compiler is GCC.
>>>> 
>>>> I agree though. We should always use the just-built Clang, and
have that behavior be opt-out (if folks need it), instead of opt-in as it is
now.
>>> 
>>> What would the build system do for a cross compile of Clang?
>>> 
>> This is the big question right? If we decide to only support building
compiler-rt with the just-built clang that inherently means that you always have
to build a clang that can run on host, so cross-compiling clang means building
for host first, then the target.
>> 
>> I don’t think that is the behavior we want.
> 
> Why not?
I don’t think you want to force anyone cross-compiling clang to also build a
host clang for compiler-rt. If there were a good reason for it I could see it
being a necessary evil, but I don’t think we have a technical reason for making
this a requirement and doubling the time of a clang cross-build seems like a
poor trade-off if we’re not getting something good in return.
> 
>> I suspect the behavior we probably want is to use the just-built clang
by default unless you are cross-compiling, in which case use the host compiler.
> 
> This sounds reasonable (and would obviously be a big improvement), but
> I'm interested in what the arguments are against the above/below.
> 
> Another option that seems superficially reasonable to me:
> 
>  - Only support building compiler-RT with the "matching" clang.
>  - When cross-compiling clang, only support the same version of clang
>    as the host (and use the host compiler).  In other words, when
>    cross-compiling, only support a two-stage build, where the first
>    stage builds a host clang, and the second stage builds the cross
>    clang.
>  - When not cross-compiling, always use the just-built clang.
This is kinda what I was getting at with the end of my email.

We could possibly say compiler-rt can only be built with clang, and is only
expected to work with clang (not as a libgcc replacement for gcc). And we could
add an additional statement that if you are cross-compiling clang you must have
a host clang that “matches” (for some definition of matches) the one you’re
building.

-Chris
> 
>> Whether or not the host compiler needs to be clang, or any version
restrictions we want to apply is a separate issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150604/4f74e102/attachment.html>

Since nobody seems to disagree with the basic idea here I’ve sent out my first
cleanup patch:

http://reviews.llvm.org/D10250 <http://reviews.llvm.org/D10250>

-Chris
> On Jun 4, 2015, at 11:32 AM, Chris Bieneman <beanz at apple.com>
wrote:
> 
> [re-sending my response to Duncan because I didn’t hit reply-all :-)]
> 
>> On Jun 3, 2015, at 1:42 PM, Duncan P. N. Exon Smith <dexonsmith at
apple.com <mailto:dexonsmith at apple.com>> wrote:
>> 
>>> 
>>> On 2015-Jun-03, at 12:57, Chris Bieneman <beanz at apple.com
<mailto:beanz at apple.com>> wrote:
>>> 
>>> 
>>>> On Jun 2, 2015, at 6:29 PM, Richard Smith <richard at
metafoo.co.uk <mailto:richard at metafoo.co.uk>> wrote:
>>>> 
>>>> On 2 Jun 2015 2:04 pm, "Jonathan Roelofs"
<jonathan at codesourcery.com <mailto:jonathan at codesourcery.com>>
wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On 6/2/15 2:38 PM, Duncan P. N. Exon Smith wrote:
>>>>>> 
>>>>>> 
>>>>>>> On 2015-Jun-01, at 19:47, Chris Bieneman <beanz
at apple.com <mailto:beanz at apple.com>> wrote:
>>>>>>> 
>>>>>>>> If we drop support for building compiler-rt
with GCC, this gets even simpler. Compiler-rt is *Clang's* runtime library,
after all.
>>>>>>> 
>>>>>>> 
>>>>>>> I don’t know if it is on the table to drop
supporting compiler-rt with GCC, but that would dramatically simplify things.
>>>>>> 
>>>>>> 
>>>>>> Weird, I'd assumed building compiler-rt with
something other than
>>>>>> clang was unsupported.  Maybe I'm missing
something, but shouldn't
>>>>>> the only supported configuration be building with the
just-built
>>>>>> clang?
>>>>> 
>>>>> 
>>>>> The current default for an in-tree build is to build
compiler-rt with whatever compiler is being used to build Clang... sometimes
that compiler is GCC.
>>>>> 
>>>>> I agree though. We should always use the just-built Clang,
and have that behavior be opt-out (if folks need it), instead of opt-in as it is
now.
>>>> 
>>>> What would the build system do for a cross compile of Clang?
>>>> 
>>> This is the big question right? If we decide to only support
building compiler-rt with the just-built clang that inherently means that you
always have to build a clang that can run on host, so cross-compiling clang
means building for host first, then the target.
>>> 
>>> I don’t think that is the behavior we want.
>> 
>> Why not?
> 
> I don’t think you want to force anyone cross-compiling clang to also build
a host clang for compiler-rt. If there were a good reason for it I could see it
being a necessary evil, but I don’t think we have a technical reason for making
this a requirement and doubling the time of a clang cross-build seems like a
poor trade-off if we’re not getting something good in return.
> 
>> 
>>> I suspect the behavior we probably want is to use the just-built
clang by default unless you are cross-compiling, in which case use the host
compiler.
>> 
>> This sounds reasonable (and would obviously be a big improvement), but
>> I'm interested in what the arguments are against the above/below.
>> 
>> Another option that seems superficially reasonable to me:
>> 
>>  - Only support building compiler-RT with the "matching"
clang.
>>  - When cross-compiling clang, only support the same version of clang
>>    as the host (and use the host compiler).  In other words, when
>>    cross-compiling, only support a two-stage build, where the first
>>    stage builds a host clang, and the second stage builds the cross
>>    clang.
>>  - When not cross-compiling, always use the just-built clang.
> 
> This is kinda what I was getting at with the end of my email.
> 
> We could possibly say compiler-rt can only be built with clang, and is only
expected to work with clang (not as a libgcc replacement for gcc). And we could
add an additional statement that if you are cross-compiling clang you must have
a host clang that “matches” (for some definition of matches) the one you’re
building.
> 
> -Chris
> 
>> 
>>> Whether or not the host compiler needs to be clang, or any version
restrictions we want to apply is a separate issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150604/2a36b502/attachment.html>

> On 2015-Jun-04, at 11:32, Chris Bieneman <beanz at apple.com> wrote:
> 
> [re-sending my response to Duncan because I didn’t hit reply-all :-)]
> 
>> On Jun 3, 2015, at 1:42 PM, Duncan P. N. Exon Smith <dexonsmith at
apple.com> wrote:
>> 
>>> 
>>> On 2015-Jun-03, at 12:57, Chris Bieneman <beanz at apple.com>
wrote:
>>> 
>>> 
>>>> On Jun 2, 2015, at 6:29 PM, Richard Smith <richard at
metafoo.co.uk> wrote:
>>>> 
>>>> On 2 Jun 2015 2:04 pm, "Jonathan Roelofs"
<jonathan at codesourcery.com> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On 6/2/15 2:38 PM, Duncan P. N. Exon Smith wrote:
>>>>>> 
>>>>>> 
>>>>>>> On 2015-Jun-01, at 19:47, Chris Bieneman <beanz
at apple.com> wrote:
>>>>>>> 
>>>>>>>> If we drop support for building compiler-rt
with GCC, this gets even simpler. Compiler-rt is *Clang's* runtime library,
after all.
>>>>>>> 
>>>>>>> 
>>>>>>> I don’t know if it is on the table to drop
supporting compiler-rt with GCC, but that would dramatically simplify things.
>>>>>> 
>>>>>> 
>>>>>> Weird, I'd assumed building compiler-rt with
something other than
>>>>>> clang was unsupported.  Maybe I'm missing
something, but shouldn't
>>>>>> the only supported configuration be building with the
just-built
>>>>>> clang?
>>>>> 
>>>>> 
>>>>> The current default for an in-tree build is to build
compiler-rt with whatever compiler is being used to build Clang... sometimes
that compiler is GCC.
>>>>> 
>>>>> I agree though. We should always use the just-built Clang,
and have that behavior be opt-out (if folks need it), instead of opt-in as it is
now.
>>>> 
>>>> What would the build system do for a cross compile of Clang?
>>>> 
>>> This is the big question right? If we decide to only support
building compiler-rt with the just-built clang that inherently means that you
always have to build a clang that can run on host, so cross-compiling clang
means building for host first, then the target.
>>> 
>>> I don’t think that is the behavior we want.
>> 
>> Why not?
> 
> I don’t think you want to force anyone cross-compiling clang to also build
a host clang for compiler-rt. If there were a good reason for it I could see it
being a necessary evil, but I don’t think we have a technical reason for making
this a requirement and doubling the time of a clang cross-build seems like a
poor trade-off if we’re not getting something good in return.
> 
>> 
>>> I suspect the behavior we probably want is to use the just-built
clang by default unless you are cross-compiling, in which case use the host
compiler.
>> 
>> This sounds reasonable (and would obviously be a big improvement), but
>> I'm interested in what the arguments are against the above/below.
>> 
>> Another option that seems superficially reasonable to me:
>> 
>>  - Only support building compiler-RT with the "matching"
clang.
>>  - When cross-compiling clang, only support the same version of clang
>>    as the host (and use the host compiler).  In other words, when
>>    cross-compiling, only support a two-stage build, where the first
>>    stage builds a host clang, and the second stage builds the cross
>>    clang.
>>  - When not cross-compiling, always use the just-built clang.
> 
> This is kinda what I was getting at with the end of my email.
> 
> We could possibly say compiler-rt can only be built with clang, and is only
expected to work with clang (not as a libgcc replacement for gcc). And we could
add an additional statement that if you are cross-compiling clang you must have
a host clang that “matches” (for some definition of matches) the one you’re
building.
This makes sense to me.