[cfe-dev] Small patches to allow fully independent clang/llvm/compiler-rt/libc++

[C Bergström via cfe-dev]

Can you guys change the subject - I don't know how this (confusing to
me and possibly JIT related) discussion has to do with the default
triple and or defaults in general.

Thanks

On Thu, Oct 15, 2015 at 6:21 PM, Renato Golin via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> On 15 October 2015 at 12:05, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote:
>> I can see the overlap between this and that. If I understand correctly, it's trying to take a JIT's ability to know exactly what the target hardware is and use that to drive normal compilation. For my case, I want the target to be what the distribution wants it to be (which is often a subset of the actual hardware) but both cases require the same ability to modify the target based on a configuration.
>
> It's actually both. And safe by being an external prototype first.
>
> The first stage is to understand the host/target machines and create a
> description (CFLAGS). The second stage is to turn that into a text
> database (JSON) so that people can add their own by hand *in addition*
> to automatically detect it.
>
> So, in your case, if Clang would understand such database, you could
> create fedora-mips-linux-gnu and debian-mips-linux-gnu configuration
> *names* (not triples) and use that to set all the flags that make
> sense for each.
>
> I believe we have to try very hard to keep compatibility with CFLAGS
> even after Clang understands the database because of other compilers.
> Once we have meaning inside the database that cannot be represented by
> flags, people will be locked in, and I want to avoid that at all
> costs. Even if the flags are ugly, they have to be standard. The
> ugliness will be hidden by the database anyway.
>
> So, a proposed format would be something like:
>
> [
>   { "name": "fedora-mips-linux-gnu",
>     "cflags": "-march=mips -mcpu=whatever --blah",
>     "arch": "arch",
>     "cpu": "cpu",
>     "endian": "blah"
>   },
> ]
>
> So, we always keep the cflags / cxxflags, even when all the other
> parameters made it redundant. The tool also has to be able to produce
> a CFLAGS from the other parameters and update the database. This way,
> it would be ludicrously simple to write a script for GCC to use this
> without asking them to implement anything on their front-end. We can
> also easily add more cflags just for gcc, icc, pcc, armcc, etc.
>
> cheers,
> --renato
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev