[LLVMdev] [RFC] Ideas on improving Compiler-RT CMake
Duncan P. N. Exon Smith
dexonsmith at apple.com
Thu Jun 4 11:57:58 PDT 2015
> 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.
More information about the llvm-dev
mailing list