[offload-arch] Print Intel GPU architecture names instead of device names

[KornevNikita]

The output of offload-arch is expected to be a list of names that are legal --offload-arch parameters, because the driver runs the utility for --offload-arch=native and feeds every line it prints to StringToOffloadArch. For Intel GPUs the utility printed the name of the device instead, e.g. Intel(R) Data Center GPU Max 1100, which is not a legal parameter.

The utility now queries the GMDID of each device with zeDeviceGetProperties and the device IP version extension (ZE_STRUCTURE_TYPE_DEVICE_IP_VERSION_EXT), and translates the architecture and release components of it into an architecture name:

• A device listed in the new IntelGPUArch.def gets a human-friendly name, which covers almost every device a user is likely to have. The revision is deliberately not part of the lookup, so a new stepping of a known architecture keeps the same name.
• Anything else is named after all three components of its GMDID, e.g. xe_40.11.0, so that a GPU newer than the compiler is still usable.

The table lives in its own .def file so that it can later be generated from the data published by the GPU driver — ocloc query SUPPORTED_DEVICES reports exactly these pairs. Where several devices share an architecture and a release, the first entry in the file names the whole group, which keeps the generator from having to pick a representative device.

Verified on an Intel Data Center GPU Max 1100 (GMDID 12.60.7): offload-arch prints xe-pvc where it used to print the device name.

Note that the driver does not accept these names yet: StringToOffloadArch currently knows only bmg_g21 among Intel GPUs, and OffloadArchToTriple returns an empty triple for Intel, so --offload-arch=native still fails after the utility prints a correct name. Wiring that up is separate work.

🤖 Generated with Claude Code

[KornevNikita]

@intel/dpcpp-cfe-reviewers could you please review this draft before I open a PR to llvm-project?
Also pinging @adurang @hansangbae as they're familiar with this tool, although both are OOO.

UPD. we decided to start with intel/llvm first.

[tahonermann]

Looks good to me.

[tahonermann]

The remaining 10 bits are all reserved for the architecture?

[KornevNikita]

Yeah, IIUC 6 first bits for revision, 8 unusued bits, 8 bits for release, 10 bits for arch.

[dm-vodopyanov]

I believe we need to merge all the patches to intel/llvm first: we don't have too much time in this release, so the 1st priority - is to deliver the feature, 2nd priority - upstream FE/etc patches.

@gmlueck @tahonermann