[PATCH] D44753: [Preprocessor] Rename __is_{target -> host}_* function-like builtin macros

[John Ericson via Phabricator via cfe-commits]

Ericson2314 added a comment.

In https://reviews.llvm.org/D44753#1044935, @bob.wilson wrote:

> Sorry that I missed your earlier comment about this. The confusion could only arise in the context of a tool (like a compiler) that is being used for cross-compilation. That is a small fraction of the audience for Clang, and we should design this in a way that makes the most sense for the majority of users. If there's a naming scheme that is better for both, then we should do that, but I don't think this is it.


I agree. But I believe mine no worse for both, and significantly better for the compiling-a-compiler case.

> When dealing with a cross compiler, there is a need to distinguish the "target" where the compiler will run (which as you point out is typically referred to as the "host") from the "target" code produced by that cross compiler.

I Agree.

> There are two points in time: (1) when compiling the cross compiler, and (2) when running the cross compiler. In step (1), the compiler will be invoked with a "-target" option that specifies the "host".

I prefer not to think times of points of time but in terms of different programs having different perspectives. The bootstrapping compiler was built on A, runs on B, and is passed `-target` for C. The new compiler was built on B, runs on C, and targets some set D... (which is not constrained). So the two compilers' frame of reference is shifted by 1, but the frame of reference per compiler is constant whether we are building it or running it.

> The compiler option name will be "-target" regardless. Using "target" names in the macros is consistent with that compiler option name.



> The obvious connection between these macros and the value specified by the "-target" option would be lost.

So I do wonder if `-target` was the best name, but agreed that ship has long since sailed.

Furthermore, with the way of per-compiler, not per-time thinking I described above, one can reconcile the `-target` flag with the autoconf terminology by saying is specifying the "target" of the compiler, not the "target" of the thing being built. Indeed, might build the new compiler like

  ./Configure 'CC=clang -target foo-bar-baz` --host foo-bar-baz --target alpha-beta-gamma
  make



> The preprocessor checks are compile-time checks, so there no way that one of these macros in the source code of the compiler itself could be referring to the target in step (2).

Yes, agreed clang won't know what the target of the compiler being built is (for that would be clang's "post target"). The problem with the status quo is that the new compiler's build system will define its own macros, and those will clash with this in very confusing ways.

For example, check out this file of GHC's https://github.com/ghc/ghc/blob/master/compiler/ghc.mk#L155-L192. The `__is_target_*` macros made by LLVM would correspond to to the `*_HOST_*` macros produces by the build system and *not* the `*_TARGET_*` ones.


Repository:
  rC Clang

https://reviews.llvm.org/D44753