[HLSL] Disable integer promotion to avoid int16_t being promoted to int for HLSL.

[python3kgae]

Summary

short will be promoted to int in UsualUnaryConversions.
Disable it for HLSL to keep int16_t as 16bit.

[aaron.ballman]

Drive-by comment before I get into the review: does HLSL intend to follow the standard in terms of behavior of intN_t? If yes, then this doesn't follow the behavior allowed by the standard or the direction WG14 chose. We discussed https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2960.pdf at our Jul 2022 meeting, and this particular topic was part of that paper. The result of the preference poll was:

Opinion poll: Which stdint.h types should be allowed to be bit-precise integer types?
0) Leave it as is - [u]intN_t may not be bit-precise, but [u]intptr_t and [u]intmax_t are unclear.
 (no one asked for this direction)
1) None of [u]intN_t, [u]intptr_t and [u]intmax_t.
 9 / 5 / 4 (this direction)
2) None of [u]intN_t, [u]intptr_t and [u]intmax_t, unless they are wider than int.
 7 / 7 / 5 (not this direction)

So we decided explicitly to not allow intN_t to be defined in terms of a bit-precise integer type.

[beanz]

HLSL deviates from C here. HLSL doesn't actually have short (although I'm actually not sure we should disable it in Clang). We do have int16_t, but we don't promote int16_t to int. We discussed changing codegen to disable promotion for HLSL, but it seemed more straightforward to me to just define int16_t as _BitInt(16).

[aaron.ballman]

In D133668#3783090, @beanz wrote:

HLSL deviates from C here. HLSL doesn't actually have short (although I'm actually not sure we should disable it in Clang). We do have int16_t, but we don't promote int16_t to int. We discussed changing codegen to disable promotion for HLSL, but it seemed more straightforward to me to just define int16_t as _BitInt(16).

Okay, that's good to know! If you don't intend to *ever* conform to the standard in this area, then I think this approach is very reasonable. But you should know up front that you're constraining yourself here. (Changing the underlying type in the future is an ABI break: https://godbolt.org/z/P6ndrzMab, note the name mangling.)

clang/lib/Basic/Targets/DirectX.h

66 ↗

(On Diff #459358)

This change requires more testing/thought, IMO -- do you support 128-bit operations? When we bump that limit to be arbitrarily high, should DX have the arbitrary limits or do you need to enforce something lower? Have you considered how you want to pack these into structures or other data layout considerations?

[beanz]

In D133668#3783489, @aaron.ballman wrote:

Okay, that's good to know! If you don't intend to *ever* conform to the standard in this area, then I think this approach is very reasonable. But you should know up front that you're constraining yourself here. (Changing the underlying type in the future is an ABI break: https://godbolt.org/z/P6ndrzMab, note the name mangling.)

We have the benefit of ABI escape hatches. HLSL itself doesn't define a permanently stable ABI since GPU hardware and runtime ABIs change too frequently. We instead revision our ABI every few years as the DirectX and Vulkan specifications evolve.

My hope is that as the HLSL language and our runtime ABIs evolve we'll be more and more conformant to the C standard, but there are some odd areas that we might never quite get there on.

The 16-bit integer math is an interesting case. Because GPUs are inherently SIMD machines, on many architectures you can handle twice as many 16-bit operations per instruction as 32-bit (yay vectors!). Combine that with HLSL's SPMD programming model and all scalar math is actually vector math. This makes integer promotion for 16-bit types severely limiting. As a result I don't suspect we'll ever want to conform to C here.

[aaron.ballman]

In D133668#3783975, @beanz wrote:

In D133668#3783489, @aaron.ballman wrote:

Okay, that's good to know! If you don't intend to *ever* conform to the standard in this area, then I think this approach is very reasonable. But you should know up front that you're constraining yourself here. (Changing the underlying type in the future is an ABI break: https://godbolt.org/z/P6ndrzMab, note the name mangling.)

We have the benefit of ABI escape hatches. HLSL itself doesn't define a permanently stable ABI since GPU hardware and runtime ABIs change too frequently. We instead revision our ABI every few years as the DirectX and Vulkan specifications evolve.

My hope is that as the HLSL language and our runtime ABIs evolve we'll be more and more conformant to the C standard, but there are some odd areas that we might never quite get there on.

The 16-bit integer math is an interesting case. Because GPUs are inherently SIMD machines, on many architectures you can handle twice as many 16-bit operations per instruction as 32-bit (yay vectors!). Combine that with HLSL's SPMD programming model and all scalar math is actually vector math. This makes integer promotion for 16-bit types severely limiting. As a result I don't suspect we'll ever want to conform to C here.

Ah, good to know!

Btw, it looks like precommit CI is finding failures here.

[python3kgae]

In D133668#3784607, @aaron.ballman wrote:

In D133668#3783975, @beanz wrote:

In D133668#3783489, @aaron.ballman wrote:

Okay, that's good to know! If you don't intend to *ever* conform to the standard in this area, then I think this approach is very reasonable. But you should know up front that you're constraining yourself here. (Changing the underlying type in the future is an ABI break: https://godbolt.org/z/P6ndrzMab, note the name mangling.)

We have the benefit of ABI escape hatches. HLSL itself doesn't define a permanently stable ABI since GPU hardware and runtime ABIs change too frequently. We instead revision our ABI every few years as the DirectX and Vulkan specifications evolve.

My hope is that as the HLSL language and our runtime ABIs evolve we'll be more and more conformant to the C standard, but there are some odd areas that we might never quite get there on.

The 16-bit integer math is an interesting case. Because GPUs are inherently SIMD machines, on many architectures you can handle twice as many 16-bit operations per instruction as 32-bit (yay vectors!). Combine that with HLSL's SPMD programming model and all scalar math is actually vector math. This makes integer promotion for 16-bit types severely limiting. As a result I don't suspect we'll ever want to conform to C here.

Ah, good to know!

Btw, it looks like precommit CI is finding failures here.

It is strange that the tests passed locally when CI hit fail in this PR. But in https://reviews.llvm.org/D133634, I hit fail locally while CI passed all tests.
I'll check and fix local failures I can repro first.

[python3kgae]

In D133668#3784636, @python3kgae wrote:

In D133668#3784607, @aaron.ballman wrote:

In D133668#3783975, @beanz wrote:

In D133668#3783489, @aaron.ballman wrote:

Okay, that's good to know! If you don't intend to *ever* conform to the standard in this area, then I think this approach is very reasonable. But you should know up front that you're constraining yourself here. (Changing the underlying type in the future is an ABI break: https://godbolt.org/z/P6ndrzMab, note the name mangling.)

We have the benefit of ABI escape hatches. HLSL itself doesn't define a permanently stable ABI since GPU hardware and runtime ABIs change too frequently. We instead revision our ABI every few years as the DirectX and Vulkan specifications evolve.

My hope is that as the HLSL language and our runtime ABIs evolve we'll be more and more conformant to the C standard, but there are some odd areas that we might never quite get there on.

The 16-bit integer math is an interesting case. Because GPUs are inherently SIMD machines, on many architectures you can handle twice as many 16-bit operations per instruction as 32-bit (yay vectors!). Combine that with HLSL's SPMD programming model and all scalar math is actually vector math. This makes integer promotion for 16-bit types severely limiting. As a result I don't suspect we'll ever want to conform to C here.

Ah, good to know!

Btw, it looks like precommit CI is finding failures here.

It is strange that the tests passed locally when CI hit fail in this PR. But in https://reviews.llvm.org/D133634, I hit fail locally while CI passed all tests.
I'll check and fix local failures I can repro first.

Might be some issue with the stack PR. Should be OK once rebase with https://reviews.llvm.org/D133634.

[beanz]

clang/lib/Basic/Targets/DirectX.h

66 ↗

(On Diff #459358)

Yea, we definitely need to set the max width to 64 for DirectX.

[python3kgae]

Rebase and update test.

[aaron.ballman]

Adding some codegen reviewers for awareness.

clang/lib/Basic/Targets/DirectX.h

66 ↗

(On Diff #459358)

Nothing seems to have handled this comment yet. Be sure to add a Sema test for that as well.

[python3kgae]

Limit max bitint width to 64 for HLSL.

[aaron.ballman]

LGTM, but please wait a bit to land for the codegen reviewers to weigh in on those tests.

[python3kgae]

Gentle ping.

[python3kgae]

Hi, @rjmccall and @efriedma,
Could you take a look at this PR?
Or should I find someone else to review it?

Thanks
Xiang

[rjmccall]

If your goal is just to pass 16-bit types in some specific way without promotion, you can just do that in the ABI. C only requires short arguments to be promoted to int in variadic or unprototyped positions, and it's not legal under the C type compatibility rules to call a function prototyped with a short parameter using an unprototyped function type. (Not that I expect that you care deeply about supporting unprototyped function calls in HLSL anyway.) So if you're looking an existing targets and feeling constrained by their ABI decision to promote small integer types, be aware that you can simply decide not to do that; those targets are mostly constrained by very old decisions that were informed by the state of languages and libraries a long time, and those decisions do not need to be carried forward to new targets.

But if you're sure you want to do this this way, your tests look fine.

[beanz]

Avoiding argument promotion is one part of what we need, but not all of it. For example if you take this trial code:

const RWBuffer<int16_t2> In;
RWBuffer<int16_t> Out;

[numthreads(1,1,1)]
void main(uint GI : SV_GroupIndex) {
  Out[GI] = In[GI].x + In[GI].y;
}

Following C rules, clang promotes the short math to int math, so the IR for main looks like:

; Function Attrs: noinline norecurse nounwind optnone
define internal void @"?main@@YAXI@Z"(i32 noundef %GI) #2 {
entry:
  %GI.addr = alloca i32, align 4
  store i32 %GI, ptr %GI.addr, align 4
  %0 = load i32, ptr %GI.addr, align 4
  %call = call noundef nonnull align 4 dereferenceable(4) ptr @"??A?$RWBuffer@T?$__vector@F$01@__clang@@@hlsl@@QBAAAT?$__vector@F$01@__clang@@I@Z"(ptr noundef nonnull align 4 dereferenceable(4) @In, i32 noundef %0)
  %1 = load <2 x i16>, ptr %call, align 4
  %2 = extractelement <2 x i16> %1, i32 0
  %conv = sext i16 %2 to i32
  %3 = load i32, ptr %GI.addr, align 4
  %call1 = call noundef nonnull align 4 dereferenceable(4) ptr @"??A?$RWBuffer@T?$__vector@F$01@__clang@@@hlsl@@QBAAAT?$__vector@F$01@__clang@@I@Z"(ptr noundef nonnull align 4 dereferenceable(4) @In, i32 noundef %3)
  %4 = load <2 x i16>, ptr %call1, align 4
  %5 = extractelement <2 x i16> %4, i32 1
  %conv2 = sext i16 %5 to i32
  %add = add nsw i32 %conv, %conv2
  %conv3 = trunc i32 %add to i16
  %6 = load i32, ptr %GI.addr, align 4
  %call4 = call noundef nonnull align 2 dereferenceable(2) ptr @"??A?$RWBuffer@F@hlsl@@QAAAAFI@Z"(ptr noundef nonnull align 4 dereferenceable(4) @"?Out@@3V?$RWBuffer@F@hlsl@@A", i32 noundef %6)
  store i16 %conv3, ptr %call4, align 2
  ret void
}

Because of the implicit vector nature of HLSL, these promotions and truncations would be extremely expensive. Using _BitInt allows us a language-header only solution that opts HLSL's [u]int16_t out of Sema::UsualUnaryConversions.

[rjmccall]

Sure, but it's extremely easy to unpromote that arithmetic for most operators, and I'm sure LLVM already has a pass that will do that. The only thing that blocks unpromotion is when you feed a promoted result into something that's sensitive to working on a wider value, like comparison or division, or of course an assignment to a wider type.

Alternatively, if you're worried about your ability to unpromote, and since you're breaking strict conformance anyway, have you considered just removing the initial promotion to int from the usual arithmetic conversions? I'm pretty sure the rest of the rules hang together just fine if you do. Then you have a uniform rule that permits easier vectorization for all small integer types rather than being sensitive specifically to using the int16_t typedef.

[beanz]

In D133668#3847163, @rjmccall wrote:

Sure, but it's extremely easy to unpromote that arithmetic for most operators, and I'm sure LLVM already has a pass that will do that.

Okay... but HLSL explicitly doesn't promote. Having the compiler rely on an optimization to generate correct code is undesirable. Especially since we want debug builds to behave correctly.

Alternatively, if you're worried about your ability to unpromote, and since you're breaking strict conformance anyway, have you considered just removing the initial promotion to int from the usual arithmetic conversions? I'm pretty sure the rest of the rules hang together just fine if you do. Then you have a uniform rule that permits easier vectorization for all small integer types rather than being sensitive specifically to using the int16_t typedef.

HLSL isn't conformant to C or C++. One of the big areas that things get wonky is that every int is actually an implicit SIMD vector of a hardware-determined size.

We could disable promotion for HLSL. That is what we do in DXC. Part of what made me think BitInt was a better solution is that HLSL doesn't have the short keyword at all. The only 16-bit int types we support are the [u]int16_t explicit-sized typedefs. If you think disabling promotion under the HLSL language mode is a better approach, we can do that instead.

[rjmccall]

In D133668#3847807, @beanz wrote:

In D133668#3847163, @rjmccall wrote:

Sure, but it's extremely easy to unpromote that arithmetic for most operators, and I'm sure LLVM already has a pass that will do that.

Okay... but HLSL explicitly doesn't promote. Having the compiler rely on an optimization to generate correct code is undesirable. Especially since we want debug builds to behave correctly.

Alternatively, if you're worried about your ability to unpromote, and since you're breaking strict conformance anyway, have you considered just removing the initial promotion to int from the usual arithmetic conversions? I'm pretty sure the rest of the rules hang together just fine if you do. Then you have a uniform rule that permits easier vectorization for all small integer types rather than being sensitive specifically to using the int16_t typedef.

HLSL isn't conformant to C or C++. One of the big areas that things get wonky is that every int is actually an implicit SIMD vector of a hardware-determined size.

But that's purely on the implementation level, right? Everything is implicitly vectorized and you're just specifying the computation of a single lane, but as far as that lane-wise computation is concerned, you just have expressions which produce scalar values.

We could disable promotion for HLSL. That is what we do in DXC. Part of what made me think BitInt was a better solution is that HLSL doesn't have the short keyword at all. The only 16-bit int types we support are the [u]int16_t explicit-sized typedefs. If you think disabling promotion under the HLSL language mode is a better approach, we can do that instead.

If you don't otherwise have 16-bit (or 8-bit?) types, and it's the type behavior you want, I'm fine with you just using _BitInt. I just want to make sure I understand the situation well enough to feel confident that you've considered the alternatives.

[beanz]

In D133668#3847871, @rjmccall wrote:

But that's purely on the implementation level, right? Everything is implicitly vectorized and you're just specifying the computation of a single lane, but as far as that lane-wise computation is concerned, you just have expressions which produce scalar values.

Yes, with the caveat that the language doesn't dictate the maximum SIMD width, but some features have minimum widths. The language source (and IR) operate on one lane of scalar and vector values, but we do have cross-SIMD lane operations, and true scalar (uniform) values, so we have to model the full breadth of parallel fun...

If you don't otherwise have 16-bit (or 8-bit?) types, and it's the type behavior you want, I'm fine with you just using _BitInt. I just want to make sure I understand the situation well enough to feel confident that you've considered the alternatives.

We don't currently have 8-bit types (although I fully expect someone will want them because ML seems to love small data types). I suspect that the promoting integer behaviors for types smaller than int will likely never make sense for HLSL (or really any SPMD/implicit-SIMD) programming model).

My inclination is that we should define all our smaller than int fixed-size integer types as _BitInt to opt-out of promotion. Along with that I expect that we'll disable short under HLSL. We will still have char, but the intent for char is really for the _extremely_ limited cases where strings get used (i.e. printf for debugging).

[rjmccall]

If you have char, would you want it to promote? Because turning char to _BitInt(8) is breaking with C on other grounds (like aliasing), for better or worse. So if you just don't want promotion, maybe you really should just disable promotion.

[python3kgae]

Switch back to short and disable integer promote for hlsl.

[python3kgae]

In D133668#3847999, @rjmccall wrote:

If you have char, would you want it to promote? Because turning char to _BitInt(8) is breaking with C on other grounds (like aliasing), for better or worse. So if you just don't want promotion, maybe you really should just disable promotion.

Hi @rjmccall,
Thanks for the review.
I've switched back to short and disabled the integer promotion for HLSL.

[rjmccall]

Okay, this seems fine to me. I think you accidentally removed the word "promotion" from the patch title, though.

I assume HLSL also provides uint16_t, and you should test the behavior for it. You should also test this for whatever 8-bit types HLSL provides (char, signed char, and unsigned char, I assume, but maybe also int8_t and uint8_t?).

clang/lib/Sema/SemaExpr.cpp

843

clang/test/CodeGenHLSL/basic_types.hlsl

7 ↗

(On Diff #468617)

Why the removal of the alignment?

[python3kgae]

Update comment and fix tests.

[aaron.ballman]

clang/lib/Sema/SemaExpr.cpp

843

Hmm, the downside to the change being applied here is that isPromotableIntegerType() is a lie for HLSL and other callers are going to be surprised. I think a better way to achieve this same goal is to move isPromotableIntegerType() from Type to ASTContext so that it has access to the language options, and then hoist the language mode check so that isPromotableIntegerType() returns false for integer types in HLSL.

[python3kgae]

Move isPromotableIntegerType to ASTContext so it can access LangOpts.

[aaron.ballman]

LGTM! Please give @rjmccall a few days to look it over as well before landing.

clang/include/clang/AST/ASTContext.h

2383

[rjmccall]

LGTM

[python3kgae]

Update test.

[python3kgae]

Fix clang-format.

clang/include/clang/AST/ASTContext.h

public:
   TypeInfoChars getTypeInfoInChars(const Type *T) const;
   TypeInfoChars getTypeInfoInChars(QualType T) const;
 
   /// Determine if the alignment the type has was required using an
   /// alignment attribute.
   bool isAlignmentRequired(const Type *T) const;
   bool isAlignmentRequired(QualType T) const;
 
+  /// More type predicates useful for type checking/promotion
+  bool isPromotableIntegerType(QualType T) const; // C99 6.3.1.1p2
+
   /// Return the "preferred" alignment of the specified type \p T for
   /// the current target, in bits.
   ///
   /// This can be different than the ABI alignment in cases where it is
   /// beneficial for performance or backwards compatibility preserving to
   /// overalign a data type. (Note: despite the name, the preferred alignment
   /// is ABI-impacting, and not an optimization.)
   unsigned getPreferredTypeAlign(QualType T) const {

clang/include/clang/AST/CanonicalType.h

public:
   LLVM_CLANG_CANPROXY_SIMPLE_ACCESSOR(bool, isOverloadableType)
   LLVM_CLANG_CANPROXY_SIMPLE_ACCESSOR(bool, isArrayType)
   LLVM_CLANG_CANPROXY_SIMPLE_ACCESSOR(bool, hasPointerRepresentation)
   LLVM_CLANG_CANPROXY_SIMPLE_ACCESSOR(bool, hasObjCPointerRepresentation)
   LLVM_CLANG_CANPROXY_SIMPLE_ACCESSOR(bool, hasIntegerRepresentation)
   LLVM_CLANG_CANPROXY_SIMPLE_ACCESSOR(bool, hasSignedIntegerRepresentation)
   LLVM_CLANG_CANPROXY_SIMPLE_ACCESSOR(bool, hasUnsignedIntegerRepresentation)
   LLVM_CLANG_CANPROXY_SIMPLE_ACCESSOR(bool, hasFloatingRepresentation)
-  LLVM_CLANG_CANPROXY_SIMPLE_ACCESSOR(bool, isPromotableIntegerType)
   LLVM_CLANG_CANPROXY_SIMPLE_ACCESSOR(bool, isSignedIntegerType)
   LLVM_CLANG_CANPROXY_SIMPLE_ACCESSOR(bool, isUnsignedIntegerType)
   LLVM_CLANG_CANPROXY_SIMPLE_ACCESSOR(bool, isSignedIntegerOrEnumerationType)
   LLVM_CLANG_CANPROXY_SIMPLE_ACCESSOR(bool, isUnsignedIntegerOrEnumerationType)
   LLVM_CLANG_CANPROXY_SIMPLE_ACCESSOR(bool, isConstantSizeType)
   LLVM_CLANG_CANPROXY_SIMPLE_ACCESSOR(bool, isSpecifierType)
   LLVM_CLANG_CANPROXY_SIMPLE_ACCESSOR(CXXRecordDecl*, getAsCXXRecordDecl)
 

clang/include/clang/AST/Type.h

#include "clang/Basic/OpenCLExtensionTypes.def"
   /// If this is a pointer, ObjC object pointer, or block
   /// pointer, this returns the respective pointee.
   QualType getPointeeType() const;
 
   /// Return the specified type with any "sugar" removed from the type,
   /// removing any typedefs, typeofs, etc., as well as any qualifiers.
   const Type *getUnqualifiedDesugaredType() const;
 
-  /// More type predicates useful for type checking/promotion
-  bool isPromotableIntegerType() const; // C99 6.3.1.1p2
-
   /// Return true if this is an integer type that is
   /// signed, according to C99 6.2.5p4 [char, signed char, short, int, long..],
   /// or an enum decl which has a signed representation.
   bool isSignedIntegerType() const;
 
   /// Return true if this is an integer type that is
   /// unsigned, according to C99 6.2.5p6 [which returns true for _Bool],
   /// or an enum decl which has an unsigned representation.

clang/include/clang/StaticAnalyzer/Core/PathSensitive/SMTConv.h

static inline void doIntTypeConversion(llvm::SMTSolverRef &Solver,
                                          ASTContext &Ctx, T &LHS, QualType &LTy,
                                          T &RHS, QualType &RTy) {
     uint64_t LBitWidth = Ctx.getTypeSize(LTy);
     uint64_t RBitWidth = Ctx.getTypeSize(RTy);
 
     assert(!LTy.isNull() && !RTy.isNull() && "Input type is null!");
     // Always perform integer promotion before checking type equality.
     // Otherwise, e.g. (bool) a + (bool) b could trigger a backend assertion
-    if (LTy->isPromotableIntegerType()) {
+    if (Ctx.isPromotableIntegerType(LTy)) {
       QualType NewTy = Ctx.getPromotedIntegerType(LTy);
       uint64_t NewBitWidth = Ctx.getTypeSize(NewTy);
       LHS = (*doCast)(Solver, LHS, NewTy, NewBitWidth, LTy, LBitWidth);
       LTy = NewTy;
       LBitWidth = NewBitWidth;
     }
-    if (RTy->isPromotableIntegerType()) {
+    if (Ctx.isPromotableIntegerType(RTy)) {
       QualType NewTy = Ctx.getPromotedIntegerType(RTy);
       uint64_t NewBitWidth = Ctx.getTypeSize(NewTy);
       RHS = (*doCast)(Solver, RHS, NewTy, NewBitWidth, RTy, RBitWidth);
       RTy = NewTy;
       RBitWidth = NewBitWidth;
     }
 
     if (LTy == RTy)

clang/lib/AST/ASTContext.cpp

TypeInfoChars ASTContext::getTypeInfoInChars(const Type *T) const {
   return TypeInfoChars(toCharUnitsFromBits(Info.Width),
                        toCharUnitsFromBits(Info.Align), Info.AlignRequirement);
 }
 
 TypeInfoChars ASTContext::getTypeInfoInChars(QualType T) const {
   return getTypeInfoInChars(T.getTypePtr());
 }
 
+bool ASTContext::isPromotableIntegerType(QualType T) const {
+  // HLSL doesn't promote all small integer types to int, it
+  // just uses the rank-based promotion rules for all types.
+  if (getLangOpts().HLSL)
+    return false;
+
+  if (const auto *BT = T->getAs<BuiltinType>())
+    switch (BT->getKind()) {
+    case BuiltinType::Bool:
+    case BuiltinType::Char_S:
+    case BuiltinType::Char_U:
+    case BuiltinType::SChar:
+    case BuiltinType::UChar:
+    case BuiltinType::Short:
+    case BuiltinType::UShort:
+    case BuiltinType::WChar_S:
+    case BuiltinType::WChar_U:
+    case BuiltinType::Char8:
+    case BuiltinType::Char16:
+    case BuiltinType::Char32:
+      return true;
+    default:
+      return false;
+    }
+
+  // Enumerated types are promotable to their compatible integer types
+  // (C99 6.3.1.1) a.k.a. its underlying type (C++ [conv.prom]p2).
+  if (const auto *ET = T->getAs<EnumType>()) {
+    if (T->isDependentType() || ET->getDecl()->getPromotionType().isNull() ||
+        ET->getDecl()->isScoped())
+      return false;
+
+    return true;
+  }
+
+  return false;
+}
+
 bool ASTContext::isAlignmentRequired(const Type *T) const {
   return getTypeInfo(T).AlignRequirement != AlignRequirementKind::None;
 }
 
 bool ASTContext::isAlignmentRequired(QualType T) const {
   return isAlignmentRequired(T.getTypePtr());
 }
 
QualType ASTContext::isPromotableBitField(Expr *E) const {
   return {};
 }
 
 /// getPromotedIntegerType - Returns the type that Promotable will
 /// promote to: C99 6.3.1.1p2, assuming that Promotable is a promotable
 /// integer type.
 QualType ASTContext::getPromotedIntegerType(QualType Promotable) const {
   assert(!Promotable.isNull());
-  assert(Promotable->isPromotableIntegerType());
+  assert(isPromotableIntegerType(Promotable));
   if (const auto *ET = Promotable->getAs<EnumType>())
     return ET->getDecl()->getPromotionType();
 
   if (const auto *BT = Promotable->getAs<BuiltinType>()) {
     // C++ [conv.prom]: A prvalue of type char16_t, char32_t, or wchar_t
     // (3.9.1) can be converted to a prvalue of the first of the following
     // types that can represent all the values of its underlying type:
     // int, unsigned int, long int, unsigned long int, long long int, or
for (unsigned i = 0, n = proto->getNumParams(); i < n; ++i) {
       // Look at the converted type of enum types, since that is the type used
       // to pass enum values.
       if (const auto *Enum = paramTy->getAs<EnumType>()) {
         paramTy = Enum->getDecl()->getIntegerType();
         if (paramTy.isNull())
           return {};
       }
 
-      if (paramTy->isPromotableIntegerType() ||
+      if (isPromotableIntegerType(paramTy) ||
           getCanonicalType(paramTy).getUnqualifiedType() == FloatTy)
         return {};
     }
 
     if (allLTypes) return lhs;
     if (allRTypes) return rhs;
 
     FunctionProtoType::ExtProtoInfo EPI = proto->getExtProtoInfo();

clang/lib/AST/FormatString.cpp

switch (K) {
     }
 
     case WIntTy: {
       QualType WInt = C.getCanonicalType(C.getWIntType()).getUnqualifiedType();
 
       if (C.getCanonicalType(argTy).getUnqualifiedType() == WInt)
         return Match;
 
-      QualType PromoArg = argTy->isPromotableIntegerType()
+      QualType PromoArg = C.isPromotableIntegerType(argTy)
                               ? C.getPromotedIntegerType(argTy)
                               : argTy;
       PromoArg = C.getCanonicalType(PromoArg).getUnqualifiedType();
 
       // If the promoted argument is the corresponding signed type of the
       // wint_t type, then it should match.
       if (PromoArg->hasSignedIntegerRepresentation() &&
           C.getCorrespondingUnsignedType(PromoArg) == WInt)

clang/lib/AST/Type.cpp

bool Type::isStdByteType() const {
   if (const auto *ET = getAs<EnumType>()) {
     IdentifierInfo *II = ET->getDecl()->getIdentifier();
     if (II && II->isStr("byte") && ET->getDecl()->isInStdNamespace())
       return true;
   }
   return false;
 }
 
-bool Type::isPromotableIntegerType() const {
-  if (const auto *BT = getAs<BuiltinType>())
-    switch (BT->getKind()) {
-    case BuiltinType::Bool:
-    case BuiltinType::Char_S:
-    case BuiltinType::Char_U:
-    case BuiltinType::SChar:
-    case BuiltinType::UChar:
-    case BuiltinType::Short:
-    case BuiltinType::UShort:
-    case BuiltinType::WChar_S:
-    case BuiltinType::WChar_U:
-    case BuiltinType::Char8:
-    case BuiltinType::Char16:
-    case BuiltinType::Char32:
-      return true;
-    default:
-      return false;
-    }
-
-  // Enumerated types are promotable to their compatible integer types
-  // (C99 6.3.1.1) a.k.a. its underlying type (C++ [conv.prom]p2).
-  if (const auto *ET = getAs<EnumType>()){
-    if (this->isDependentType() || ET->getDecl()->getPromotionType().isNull()
-        || ET->getDecl()->isScoped())
-      return false;
-
-    return true;
-  }
-
-  return false;
-}
-
 bool Type::isSpecifierType() const {
   // Note that this intentionally does not use the canonical type.
   switch (getTypeClass()) {
   case Builtin:
   case Record:
   case Enum:
   case Typedef:
   case Complex:

clang/lib/CodeGen/CGExprScalar.cpp

 /// If \p E is a widened promoted integer, get its base (unpromoted) type.
 static llvm::Optional<QualType> getUnwidenedIntegerType(const ASTContext &Ctx,
                                                         const Expr *E) {
   const Expr *Base = E->IgnoreImpCasts();
   if (E == Base)
     return llvm::None;
 
   QualType BaseTy = Base->getType();
-  if (!BaseTy->isPromotableIntegerType() ||
+  if (!Ctx.isPromotableIntegerType(BaseTy) ||
       Ctx.getTypeSize(BaseTy) >= Ctx.getTypeSize(E->getType()))
     return llvm::None;
 
   return BaseTy;
 }
 
 /// Check if \p E is a widened promoted integer.
 static bool IsWidenedIntegerOp(const ASTContext &Ctx, const Expr *E) {
ScalarExprEmitter::EmitScalarPrePostIncDec(const UnaryOperator *E, LValue LV,
   // Decrement does not have this property.
   if (isInc && type->isBooleanType()) {
     value = Builder.getTrue();
 
   // Most common case by far: integer increment.
   } else if (type->isIntegerType()) {
     QualType promotedType;
     bool canPerformLossyDemotionCheck = false;
-    if (type->isPromotableIntegerType()) {
+    if (CGF.getContext().isPromotableIntegerType(type)) {
       promotedType = CGF.getContext().getPromotedIntegerType(type);
       assert(promotedType != type && "Shouldn't promote to the same type.");
       canPerformLossyDemotionCheck = true;
       canPerformLossyDemotionCheck &=
           CGF.getContext().getCanonicalType(type) !=
           CGF.getContext().getCanonicalType(promotedType);
       canPerformLossyDemotionCheck &=
           PromotionIsPotentiallyEligibleForImplicitIntegerConversionCheck(

clang/lib/CodeGen/TargetInfo.cpp

 }
 
 static llvm::Type *getVAListElementType(CodeGenFunction &CGF) {
   return CGF.ConvertTypeForMem(
       CGF.getContext().getBuiltinVaListType()->getPointeeType());
 }
 
 bool ABIInfo::isPromotableIntegerTypeForABI(QualType Ty) const {
-  if (Ty->isPromotableIntegerType())
+  if (getContext().isPromotableIntegerType(Ty))
     return true;
 
   if (const auto *EIT = Ty->getAs<BitIntType>())
     if (EIT->getNumBits() < getContext().getTypeSize(getContext().IntTy))
       return true;
 
   return false;
 }

 // Return true if the ABI requires Ty to be passed sign- or zero-
 // extended to 32/64 bits.
 bool AIXABIInfo::isPromotableTypeForABI(QualType Ty) const {
   // Treat an enum type as its underlying type.
   if (const EnumType *EnumTy = Ty->getAs<EnumType>())
     Ty = EnumTy->getDecl()->getIntegerType();
 
   // Promotable integer types are required to be promoted by the ABI.
-  if (Ty->isPromotableIntegerType())
+  if (getContext().isPromotableIntegerType(Ty))
     return true;
 
   if (!Is64Bit)
     return false;
 
   // For 64 bit mode, in addition to the usual promotable integer types, we also
   // need to extend all 32-bit types, since the ABI requires promotion to 64
   // bits.

clang/lib/Sema/SemaChecking.cpp

bool Sema::SemaBuiltinVAStart(unsigned BuiltinID, CallExpr *TheCall) {
 
   if (!SecondArgIsLastNamedArgument)
     Diag(TheCall->getArg(1)->getBeginLoc(),
          diag::warn_second_arg_of_va_start_not_last_named_param);
   else if (IsCRegister || Type->isReferenceType() ||
            Type->isSpecificBuiltinType(BuiltinType::Float) || [=] {
              // Promotable integers are UB, but enumerations need a bit of
              // extra checking to see what their promotable type actually is.
-             if (!Type->isPromotableIntegerType())
+             if (!Context.isPromotableIntegerType(Type))
                return false;
              if (!Type->isEnumeralType())
                return true;
              const EnumDecl *ED = Type->castAs<EnumType>()->getDecl();
              return !(ED &&
                       Context.typesAreCompatible(ED->getPromotionType(), Type));
            }()) {
     unsigned Reason = 0;

 /// type do not count.
 static bool
 isArithmeticArgumentPromotion(Sema &S, const ImplicitCastExpr *ICE) {
   QualType From = ICE->getSubExpr()->getType();
   QualType To = ICE->getType();
   // It's an integer promotion if the destination type is the promoted
   // source type.
   if (ICE->getCastKind() == CK_IntegralCast &&
-      From->isPromotableIntegerType() &&
+      S.Context.isPromotableIntegerType(From) &&
       S.Context.getPromotedIntegerType(From) == To)
     return true;
   // Look through vector types, since we do default argument promotion for
   // those in OpenCL.
   if (const auto *VecTy = From->getAs<ExtVectorType>())
     From = VecTy->getElementType();
   if (const auto *VecTy = To->getAs<ExtVectorType>())
     To = VecTy->getElementType();

clang/lib/Sema/SemaDecl.cpp

if (Kind == TTK_Enum) {
         return nullptr;
       if (EnumUnderlying) {
         EnumDecl *ED = cast<EnumDecl>(New);
         if (TypeSourceInfo *TI = EnumUnderlying.dyn_cast<TypeSourceInfo *>())
           ED->setIntegerTypeSourceInfo(TI);
         else
           ED->setIntegerType(QualType(EnumUnderlying.get<const Type *>(), 0));
         QualType EnumTy = ED->getIntegerType();
-        ED->setPromotionType(EnumTy->isPromotableIntegerType()
+        ED->setPromotionType(Context.isPromotableIntegerType(EnumTy)
                                  ? Context.getPromotedIntegerType(EnumTy)
                                  : EnumTy);
       }
     } else { // struct/union
       New = RecordDecl::Create(Context, Kind, SearchDC, KWLoc, Loc, Name,
                                nullptr);
     }
 
if (Kind == TTK_Enum) {
 
     if (EnumUnderlying) {
       EnumDecl *ED = cast<EnumDecl>(New);
       if (TypeSourceInfo *TI = EnumUnderlying.dyn_cast<TypeSourceInfo*>())
         ED->setIntegerTypeSourceInfo(TI);
       else
         ED->setIntegerType(QualType(EnumUnderlying.get<const Type *>(), 0));
       QualType EnumTy = ED->getIntegerType();
-      ED->setPromotionType(EnumTy->isPromotableIntegerType()
+      ED->setPromotionType(Context.isPromotableIntegerType(EnumTy)
                                ? Context.getPromotedIntegerType(EnumTy)
                                : EnumTy);
       assert(ED->isComplete() && "enum with type should be complete");
     }
   } else {
     // struct/union/class
 
     // FIXME: Tag decls should be chained to any simultaneous vardecls, e.g.:
void Sema::ActOnEnumBody(SourceLocation EnumLoc, SourceRange BraceRange,
   // enum definitions.
   if (LangOpts.ShortEnums)
     Packed = true;
 
   // If the enum already has a type because it is fixed or dictated by the
   // target, promote that type instead of analyzing the enumerators.
   if (Enum->isComplete()) {
     BestType = Enum->getIntegerType();
-    if (BestType->isPromotableIntegerType())
+    if (Context.isPromotableIntegerType(BestType))
       BestPromotionType = Context.getPromotedIntegerType(BestType);
     else
       BestPromotionType = BestType;
 
     BestWidth = Context.getIntWidth(BestType);
   }
   else if (NumNegativeBits) {
     // If there is a negative value, figure out the smallest integer type (of

clang/lib/Sema/SemaExpr.cpp

if (Ty->isIntegralOrUnscopedEnumerationType()) {
     //   unsigned int. These are called the integer promotions. All
     //   other types are unchanged by the integer promotions.
 
     QualType PTy = Context.isPromotableBitField(E);
     if (!PTy.isNull()) {
       E = ImpCastExprToType(E, PTy, CK_IntegralCast).get();
       return E;
     }
-    if (Ty->isPromotableIntegerType()) {
+    if (Context.isPromotableIntegerType(Ty)) {
       QualType PT = Context.getPromotedIntegerType(Ty);
       E = ImpCastExprToType(E, PT, CK_IntegralCast).get();
       return E;
     }
   }
   return E;
 }
 
 /// DefaultArgumentPromotion (C99 6.5.2.2p6). Used for function calls that
QualType Sema::UsualArithmeticConversions(ExprResult &LHS, ExprResult &RHS,
 
   // If either side is a non-arithmetic type (e.g. a pointer), we are done.
   // The caller can deal with this (e.g. pointer + int).
   if (!LHSType->isArithmeticType() || !RHSType->isArithmeticType())
     return QualType();
 
   // Apply unary and bitfield promotions to the LHS's type.
   QualType LHSUnpromotedType = LHSType;
-  if (LHSType->isPromotableIntegerType())
+  if (Context.isPromotableIntegerType(LHSType))
     LHSType = Context.getPromotedIntegerType(LHSType);
   QualType LHSBitfieldPromoteTy = Context.isPromotableBitField(LHS.get());
   if (!LHSBitfieldPromoteTy.isNull())
     LHSType = LHSBitfieldPromoteTy;
   if (LHSType != LHSUnpromotedType && ACK != ACK_CompAssign)
     LHS = ImpCastExprToType(LHS.get(), LHSType, CK_IntegralCast);
 
   // If both types are identical, no conversion is needed.
QualType Sema::CheckAdditionOperands(ExprResult &LHS, ExprResult &RHS,
 
   // Check array bounds for pointer arithemtic
   CheckArrayAccess(PExp, IExp);
 
   if (CompLHSTy) {
     QualType LHSTy = Context.isPromotableBitField(LHS.get());
     if (LHSTy.isNull()) {
       LHSTy = LHS.get()->getType();
-      if (LHSTy->isPromotableIntegerType())
+      if (Context.isPromotableIntegerType(LHSTy))
         LHSTy = Context.getPromotedIntegerType(LHSTy);
     }
     *CompLHSTy = LHSTy;
   }
 
   return PExp->getType();
 }
 
if (NumEnumArgs == 2) {
     }
     QualType IntType =
         LHSStrippedType->castAs<EnumType>()->getDecl()->getIntegerType();
     assert(IntType->isArithmeticType());
 
     // We can't use `CK_IntegralCast` when the underlying type is 'bool', so we
     // promote the boolean type, and all other promotable integer types, to
     // avoid this.
-    if (IntType->isPromotableIntegerType())
+    if (S.Context.isPromotableIntegerType(IntType))
       IntType = S.Context.getPromotedIntegerType(IntType);
 
     LHS = S.ImpCastExprToType(LHS.get(), IntType, CK_IntegralCast);
     RHS = S.ImpCastExprToType(RHS.get(), IntType, CK_IntegralCast);
     LHSType = RHSType = IntType;
   }
 
   // C++2a [expr.spaceship]p4: If both operands have arithmetic types, the
ExprResult Sema::BuildBinOp(Scope *S, SourceLocation OpLoc,
   // Build a built-in binary operation.
   return CreateBuiltinBinOp(OpLoc, Opc, LHSExpr, RHSExpr);
 }
 
 static bool isOverflowingIntegerType(ASTContext &Ctx, QualType T) {
   if (T.isNull() || T->isDependentType())
     return false;
 
-  if (!T->isPromotableIntegerType())
+  if (!Ctx.isPromotableIntegerType(T))
     return true;
 
   return Ctx.getIntWidth(T) >= Ctx.getIntWidth(Ctx.IntTy);
 }
 
 ExprResult Sema::CreateBuiltinUnaryOp(SourceLocation OpLoc,
                                       UnaryOperatorKind Opc, Expr *InputExpr,
                                       bool IsAfterAmp) {
if (!TInfo->getType().isPODType(Context)) {
              : diag::warn_second_parameter_to_va_arg_not_pod)
         << TInfo->getType()
         << TInfo->getTypeLoc().getSourceRange();
     }
 
     // Check for va_arg where arguments of the given type will be promoted
     // (i.e. this va_arg is guaranteed to have undefined behavior).
     QualType PromoteType;
-    if (TInfo->getType()->isPromotableIntegerType()) {
+    if (Context.isPromotableIntegerType(TInfo->getType())) {
       PromoteType = Context.getPromotedIntegerType(TInfo->getType());
       // [cstdarg.syn]p1 defers the C++ behavior to what the C standard says,
       // and C2x 7.16.1.1p2 says, in part:
       //   If type is not compatible with the type of the actual next argument
       //   (as promoted according to the default argument promotions), the
       //   behavior is undefined, except for the following cases:
       //     - both types are pointers to qualified or unqualified versions of
       //       compatible types;

clang/lib/Sema/SemaInit.cpp

if (IsStringLiteralInitUpdate && VerifyOnly) {
     ASTContext &Context = SemaRef.Context;
     Expr *SubExpr = StructuredList->getInit(0)->IgnoreParenImpCasts();
 
     // Compute the character type
     QualType CharTy = AT->getElementType();
 
     // Compute the type of the integer literals.
     QualType PromotedCharTy = CharTy;
-    if (CharTy->isPromotableIntegerType())
+    if (Context.isPromotableIntegerType(CharTy))
       PromotedCharTy = Context.getPromotedIntegerType(CharTy);
     unsigned PromotedCharTyWidth = Context.getTypeSize(PromotedCharTy);
 
     if (StringLiteral *SL = dyn_cast<StringLiteral>(SubExpr)) {
       // Get the length of the string.
       uint64_t StrLen = SL->getLength();
       if (cast<ConstantArrayType>(AT)->getSize().ult(StrLen))
         StrLen = cast<ConstantArrayType>(AT)->getSize().getZExtValue();

clang/lib/Sema/SemaOverload.cpp

if (!To) {
     return false;
   }
 
   // An rvalue of type char, signed char, unsigned char, short int, or
   // unsigned short int can be converted to an rvalue of type int if
   // int can represent all the values of the source type; otherwise,
   // the source rvalue can be converted to an rvalue of type unsigned
   // int (C++ 4.5p1).
-  if (FromType->isPromotableIntegerType() && !FromType->isBooleanType() &&
+  if (Context.isPromotableIntegerType(FromType) && !FromType->isBooleanType() &&
       !FromType->isEnumeralType()) {
-    if (// We can promote any signed, promotable integer type to an int
+    if ( // We can promote any signed, promotable integer type to an int
         (FromType->isSignedIntegerType() ||
          // We can promote any unsigned integer type whose size is
          // less than int to an int.
          Context.getTypeSize(FromType) < Context.getTypeSize(ToType))) {
       return To->getKind() == BuiltinType::Int;
     }
 
     return To->getKind() == BuiltinType::UInt;

clang/lib/Sema/SemaType.cpp

case DeclaratorChunk::Function: {
               }
             } else if (!S.getLangOpts().NativeHalfArgsAndReturns &&
                        !S.Context.getTargetInfo().allowHalfArgsAndReturns()) {
               S.Diag(Param->getLocation(),
                 diag::err_parameters_retval_cannot_have_fp16_type) << 0;
               D.setInvalidType();
             }
           } else if (!FTI.hasPrototype) {
-            if (ParamTy->isPromotableIntegerType()) {
+            if (Context.isPromotableIntegerType(ParamTy)) {
               ParamTy = Context.getPromotedIntegerType(ParamTy);
               Param->setKNRPromoted(true);
-            } else if (const BuiltinType* BTy = ParamTy->getAs<BuiltinType>()) {
+            } else if (const BuiltinType *BTy = ParamTy->getAs<BuiltinType>()) {
               if (BTy->getKind() == BuiltinType::Float) {
                 ParamTy = Context.DoubleTy;
                 Param->setKNRPromoted(true);
               }
             }
           } else if (S.getLangOpts().OpenCL && ParamTy->isBlockPointerType()) {
             // OpenCL 2.0 s6.12.5: A block cannot be a parameter of a function.
             S.Diag(Param->getLocation(), diag::err_opencl_invalid_param)

clang/test/CodeGenHLSL/builtins/abs.hlsl

 // RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
 // RUN:   dxil-pc-shadermodel6.3-library %s -fnative-half-type \
 // RUN:   -emit-llvm -disable-llvm-passes -O3 -o - | FileCheck %s
 // RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
 // RUN:   dxil-pc-shadermodel6.3-library %s -emit-llvm -disable-llvm-passes \
 // RUN:   -D__HLSL_ENABLE_16_BIT -o - | FileCheck %s --check-prefix=NO_HALF
 
 using hlsl::abs;
 
-// CHECK: define noundef signext i16 @
-// FIXME: int16_t is promoted to i32 now. Change to abs.i16 once it is fixed.
-// CHECK: call i32 @llvm.abs.i32(
+// CHECK: define noundef i16 @
+// CHECK: call i16 @llvm.abs.i16(
 int16_t test_abs_int16_t ( int16_t p0 ) {
   return abs ( p0 );
 }
 // CHECK: define noundef <2 x i16> @
 // CHECK: call <2 x i16> @llvm.abs.v2i16(
 int16_t2 test_abs_int16_t2 ( int16_t2 p0 ) {
   return abs ( p0 );
 }

clang/test/CodeGenHLSL/no_int_promotion.hlsl

+// RUN: %clang_cc1 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -D__HLSL_ENABLE_16_BIT \
+// RUN:   -emit-llvm -disable-llvm-passes -O3 -o - | FileCheck %s
+
+// FIXME: add test for char/int8_t/uint8_t when these types are supported in HLSL.
+//  See https://github.com/llvm/llvm-project/issues/58453.
+
+// Make sure generate i16 add.
+// CHECK: add nsw i16 %
+int16_t add(int16_t a, int16_t b) {
+  return a + b;
+}
+// CHECK: define noundef <2 x i16> @
+// CHECK: add <2 x i16>
+int16_t2 add(int16_t2 a, int16_t2 b) {
+  return a + b;
+}
+// CHECK: define noundef <3 x i16> @
+// CHECK: add <3 x i16>
+int16_t3 add(int16_t3 a, int16_t3 b) {
+  return a + b;
+}
+// CHECK: define noundef <4 x i16> @
+// CHECK: add <4 x i16>
+int16_t4 add(int16_t4 a, int16_t4 b) {
+  return a + b;
+}
+// CHECK: define noundef i16 @
+// CHECK: add i16 %
+uint16_t add(uint16_t a, uint16_t b) {
+  return a + b;
+}
+// CHECK: define noundef <2 x i16> @
+// CHECK: add <2 x i16>
+uint16_t2 add(uint16_t2 a, uint16_t2 b) {
+  return a + b;
+}
+// CHECK: define noundef <3 x i16> @
+// CHECK: add <3 x i16>
+uint16_t3 add(uint16_t3 a, uint16_t3 b) {
+  return a + b;
+}
+// CHECK: define noundef <4 x i16> @
+// CHECK: add <4 x i16>
+uint16_t4 add(uint16_t4 a, uint16_t4 b) {
+  return a + b;
+}

clang/test/SemaHLSL/BitInt128.hlsl

+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -x hlsl -ast-dump -o - %s -verify
+
+// expected-error@+1 {{_BitInt is not supported on this target}}
+_BitInt(128) i128;
+
+// expected-error@+1 {{_BitInt is not supported on this target}}
+unsigned _BitInt(128) u128;