The target triple and data layout should follow from --machine / --host, not a separate --target

--target sets the module's triple and data layout, and is independent of the machine and host models:

// src/driver.rs
fn target_triple_and_datalayout(target: &str) -> Option<(&'static str, &'static str)> {
    match target {
        "x86_64"  => Some(("x86_64-unknown-linux-gnu", "e-m:e-p270:32:32-...")),
        "aarch64" => Some(("aarch64-unknown-linux-gnu", "e-m:e-i8:8:32-...")),
        "nvptx64" => Some(("nvptx64-nvidia-cuda", "e-i64:64-i128:128-...")),
        "amdgcn"  => Some(("amdgcn-amd-amdhsa", "e-p:64:64-p1:64:64-...")),
        _ => None,
    }
}

Nothing ties it to --machine or --host, so this is accepted without comment:

vxc prog.vx --host <an x86 host file> --machine fleet/a100-80.vx --target aarch64

A program admitted against one machine and emitted for another. The compiler holds both beliefs and never compares them.

What it should be

A machine model already says everything a triple says, and more. The flags should imply it:

• --host gives the host triple and layout, which the module carries: main, the dispatch calls, the outlined kernels' C interfaces.
• --machine gives the device triple and layout, for the gpu.module once kernel emission lands (#251).
• --target, if it survives, becomes an override that must agree with the declarations, with a mismatch as a diagnostic.

Why it is worth doing

Cross-compilation becomes ordinary. Build on a laptop for an x86 host with an A100 attached. scripts/make_gpu_bundle.sh ships a compiler to a rented pod partly because the compiler can only emit for the machine it runs on; deriving the target from a declaration is what removes that constraint, and it is the same constraint behind hiraditya/Vx.1#332 (AOT emission failing means the object cannot be built on the build box and copied).

The incoherent combination stops being expressible. A triple derived from a declaration cannot contradict it.

It gives a host file a reason to name its architecture. fleet/host-x86-e5-2666v3.vx declares bandwidth and says nothing about the instruction set -- a gap only because nothing needed it. The device side already has some of this: src/arch.rs maps a MemorySpace to an NVPTX address space (#258), so the address-space portion of a device data layout is derivable today.

Shape

An arch: field in machine and host declarations, the triple looked up from it, --target demoted to an override, and disagreement made an error. Then --machine plus --host fully determine what is emitted as well as what is admitted, which is what makes the fleet model a target description rather than only an admission oracle.

Related: hiraditya/Vx.1#341 (--host), hiraditya/Vx.1#319 (the demo), hiraditya/Vx.1#251 (device kernel emission), hiraditya/Vx.1#258 (address spaces), hiraditya/Vx.1#332 (AOT).

Start in src/driver.rs with target_triple_and_datalayout, then read src/arch.rs and the related machine and host declaration handling. Trace how --host, --machine, and --target currently reach module emission. Done means declarations determine host and device target data, while any retained --target disagreement produces a diagnostic.