Hi James, Renato, I'm replying to this one with the full review since it'll make things a little easier to talk about.
First of all, I really like the direction you're going with this patch! I've been wanting a tablegen oriented toolchain. > OK, currently if I want to cross-compile for ARM, I have to use the > -ccc-host-triple option: > > clang -ccc-host-triple armv7 Yes. This is somewhat deplorable. > > I can then use -march and -mcpu to select microarchitectures and CPUs. > However, it seems very strange that if a user does: > > clang -march=armv7 > > which is the obvious thing to do to select the target architecture, clang > will not recognise this as it tries to interpret armv7 as an intel sub arch. Actually, I think this is correct though doesn't quite match what a user accustomed to gcc would expect. I would expect that were you compiling natively on an arm host that this would get you what you expect. :) > This patch/set of patches tries to fix this, and in doing so fix several > FIXME's in the Driver code also. So after the patch is applied, the user can > do > one of many things: > > clang -march=armv7 # Selects an ARMv7 core. > clang -mcpu=cortex-a8 # Does what it says on the tin > clang -mcpu=yonah # Selects an intel core - implicitly set the > architecture to i686 (IIRC) > clang -ccc-host-triple=armv7 # Same behaviour as previously > > The multi-arch Darwin fat-binary support is totally unaffected, this only > applies to single-arch mode. Ideally I don't think that the two of these should affect anything. Here's how I see it going which I think is a distance from your patch from the way it's currently written, but similar in direction. I'd thought about using your patch as a basis, but wanted to talk to you about it first. A few notes on how I view things: First of all since we're going for a true universal driver the old gcc way of identifying arch, cpu and tune for a cross compile should be thrown out the window. Especially since I, for example, wrote the mips support and it doesn't agree with the arm support ;) -arch <x> The way we select the architecture we're compiling for if it isn't the default cpu. -march <x> The way we select a sub arch of the architecture specified in #1, this can also be seen as a bad way of doing things since -arch should support the full range of cpu names. -mcpu <x> Honestly an even worse way, however, arm people are somewhat accustomed to this as well. -ccc-host-triple <x> This should never be used, however, I'd definitely like to start with a -triple or a -target (preferred) to specify what would be a full target triple as a way of compiling. > The patch, after review, also added a "-mos=" option to change the > OS/Environment part of the target triple. This was suggested as -march + > -mcpu weren't quite powerful enough by themselves to completely replace > -ccc-host-triple in functionality. For example, the following two invocations > are identical: > > clang -ccc-host-triple armv7-freebsd-eabi > clang -march=armv7 -mos=freebsd-eabi > > Hopefully this all makes sense - I've had the -arch support in mind when > designing the patch and have tried not to break anything fundamental; > obviously that somewhat depends on how full-featured the driver regression > tests for Darwin are... ;) I can see where you're going with this, I think I'd rather use -target for this sort of situation though. More options aren't necessarily better. :) So, in my ideal world, here's how I think this would work: clang -arch foo This will compile for the architecture listed with the current os and environment of the host clang -target a-b-c This will compile for the full triple listed, or alternately, whatever we think is reasonable to parse out of the target field (i.e. we may want more options in order to decide which toolchain to pick) clang -march This unfortunate option is around for compatibility, it'll select a sub arch if used from a single architecture compile, error otherwise. clang -mcpu Ditto. clang -mtune Slightly more interesting here. It should definitely error if there's more than one architecture listed for now, but there's definitely room for a "I want a way to tune for an architecture, but run on a different one" Under the covers we'll want to support things like OS headers, libraries, subprograms to invoke based on the actual "toolchain" we've selected from the universal driver. In this case "toolchain" means a target with associated directives for compiling, assembling, linking, etc including cross compilation support. I'd like to get most, if not all, of these from within a tablegen description as well. What do you think? Does anyone else have any additional comments? Keep in mind that comments should be backed up with code (or proven code history in this area) I don't want this to turn into a bike shed discussion. -eric _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
