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

Richard Smith via cfe-dev cfe-dev at lists.llvm.org
Thu Oct 15 12:41:28 PDT 2015


On Oct 15, 2015 4:21 AM, "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'm not sure what distinction you're trying to draw here, given that
"configuration names" is the proper term for the thing we inaccurately call
a triple (see https://www.sourceware.org/autobook/autobook/autobook_17.html
).

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151015/f1a5a5d1/attachment.html>


More information about the cfe-dev mailing list