================
@@ -760,7 +760,7 @@ using namespace clang::targets;
TargetInfo *
TargetInfo::CreateTargetInfo(DiagnosticsEngine &Diags,
const std::shared_ptr<TargetOptions> &Opts) {
- llvm::Triple Triple(Opts->Triple);
+ llvm::Triple Triple(llvm::Triple::normalize(Opts->Triple));
----------------
bharadwajy wrote:
> I see. It is trying to add subarch for dxil. Could we allow Triple::NoSubArch
> for dxil?
`setArch(dxil, Triple::NoSubArch)` should work.
> Backend could do the job to translate NoSubArch to the version based on
> shader model.
One of the principles I tried to adhere to in the implementation of part (2) is
to pass an appropriately constructed DXIL target triple string at creation-time
of (DXIL) TargetMachine instance to maintain consistency between all the fields
of the instance of DXIL `Triple` viz., Data, Arch, SubArch etc.
Delegating or expecting the backend to do the same may lead to inconsistencies
in the Triple instance. What benefit do you see in letting Backend perform the
same steps that can be performed at creation time? Of course, if the backend
needs to change the triple information for any reason, it is still free to do
so - but I think it should expect to have the target triple information that
reflects command-line or IR module specification of target triple.
https://github.com/llvm/llvm-project/pull/90809
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
