This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Add Android related compilation options and multilib options

On Jun 16, 2009, at 4:35 PM, Joseph S. Myers wrote:
On Tue, 16 Jun 2009, Chris Lattner wrote:

powerpc-linux is a good case in point of having too many triplets, with
variants such as powerpc64-*-linux*, powerpc-*-linux*spe*,
powerpc-*-linux*paired*, powerpc*-*-linux*altivec* that should just be
variants on the default options and multilibs for one target triplet.

Why is "more targets bad"? Life seems simple if you have one set of libraries
for each target triple, so you have a "many target triples to one set of
libraries" mapping. This implies that the major ABI differences get different
triples though.

If life seems simple you clearly haven't tried working at and beyond the
limits of what GCC's multilib configuration supports,

I will eagerly admit that I have not :)

with large numbers
of libraries and complicated mappings from the command line options used
to which runtime libraries to link with. There are options where you
don't have the one set of libraries per multilib either; consider how
ARM's linker can select objects based on build attributes rather than
based on options passed to the compiler, or the interest from S/390 people
in having separate hard-DFP versions of libgcc but not of libc, or the
STT_GNU_IFUNC approach to optimized functions. Configuration with large
numbers of libraries is essentially complicated and you should understand
the existing systems first before proclaiming (cf. Rob Landley's blog)
that some massively simpler system can solve all the problems in this
area; such claims suggest that only a much narrower range of
configurations has actually been thought about.

I'm also not familiar with Rob Landley's blog.

When you have multiple triplets for essentially the same configuration,
every case statement in configuration, and every testcase, that wishes to
test for the configuration, needs to match all the variants, and
everything that should be in common between the configurations needs to be
kept in sync - and in practice those powerpc*-linux* targets have got out
of sync in the past, and testcases have not been properly conditioned to
run for the correct targets and only the correct targets, and fixing up
incorrect testsuite presumptions in this area was a pain. There isn't
even a meaningful distinction between powerpc64-linux and powerpc- linux
given that the former is usually built to default to 32-bit with
--with-cpu=default32. If you want a compiler that supports both 64- bit
and SPE multilibs, having them in different targets is no good. The
benefits to maintainability of reducing the proliferation of triplets are
very clear.

Ah interesting. I certainly wasn't considering how the GCC testsuite works and what its requirements are. Basing the testsuite on the *input* triple to the compiler seems to have many complexities.

It's worth pointing out that LLVM does a bit of canonicalization of target triples internally to collapse actually identical triples into a canonical form (e.g. i[3456]x86-* -> i386-*). Also, in your example of a powerpc64-linux compiler, the front-end actually sets the triple appropriately for later phases of codegen and linking to powerpc- linux, not powerpc64-linux. Setting the triple to powerpc64-linux when generating 32-bit code seems very strange and I can see how you've grown a distrust for target triples. :)

Getting this right is important for us because later phases of codegen are driven by the triple, not by random state floating around in compiler global variables.

And there is an essentially infinite number of possible configurations
determined by particular options one might want to enable by default;
converting sets of options into the syntax of target triplets would lead
to a lot of very long and obscure triplets; configure options such as
--with-cpu work a lot better and there's no good reason for "default -m64"
to be handled differently with its own triplet. Target triplets are not
meant to encapsulate everything possible about how you might choose to
configure GCC; there's a reason there are lots of other configure options
and options that can be used when running GCC.

Right, we don't encode every cpu capability into the triple.

It has been very clear in the process of cleaning up support for unused
and obsolete targets that a proliferation of "canonical" target names
(names that are distinct after being passed through config.sub) is a bad
idea. Noncanonical aliases that imply different configuration choices are
rather less problematic.

It sounds like there are many possible areas for improvement. In any case, I will butt out and let you guys figure out how to solve this issue with Android. I am very happy to admit that I have no idea how your toolchain should work.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]