[clang] [Clang] [Sema] Don't crash on unexpanded pack in invalid block literal (PR #110762)

2024-10-02 Thread John McCall via cfe-commits
rjmccall wrote: I don't think there's a deep reason blocks and lambdas don't use quite the same scope mechanics in the compiler, so if you wanted to pursue that, it seems reasonable. But this approach also seems viable. I agree that removing the assertion would be the wrong thing to do, and

[clang] [PAC] Re-sign a pointer to a noexcept member function when it is converted to a pointer to a member function without noexcept (PR #109056)

2024-09-19 Thread John McCall via cfe-commits
https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/109056 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [PAC] Re-sign a pointer to a noexcept member function when it is converted to a pointer to a member function without noexcept (PR #109056)

2024-09-19 Thread John McCall via cfe-commits
@@ -2419,8 +2419,13 @@ Value *ScalarExprEmitter::VisitCastExpr(CastExpr *CE) { return Visit(const_cast(E)); case CK_NoOp: { -return CE->changesVolatileQualification() ? EmitLoadOfLValue(CE) - : Visit(const_cast(E)); +i

[clang] [PAC] Re-sign a pointer to a noexcept member function when it is converted to a pointer to a member function without noexcept (PR #109056)

2024-09-18 Thread John McCall via cfe-commits
@@ -2419,8 +2419,13 @@ Value *ScalarExprEmitter::VisitCastExpr(CastExpr *CE) { return Visit(const_cast(E)); case CK_NoOp: { -return CE->changesVolatileQualification() ? EmitLoadOfLValue(CE) - : Visit(const_cast(E)); +i

[clang] [PAC] Re-sign a pointer to a noexcept member function when it is converted to a pointer to a member function without noexcept (PR #109056)

2024-09-18 Thread John McCall via cfe-commits
@@ -2419,8 +2419,13 @@ Value *ScalarExprEmitter::VisitCastExpr(CastExpr *CE) { return Visit(const_cast(E)); case CK_NoOp: { -return CE->changesVolatileQualification() ? EmitLoadOfLValue(CE) - : Visit(const_cast(E)); +i

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-30 Thread John McCall via cfe-commits
https://github.com/rjmccall approved this pull request. Thanks, LGTM. https://github.com/llvm/llvm-project/pull/101083 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-30 Thread John McCall via cfe-commits
@@ -11427,6 +11427,19 @@ static void AnalyzeImplicitConversions( return; } + if (auto *OutArgE = dyn_cast(E)) { +// The base expression is only used to initialize the parameter for +// arguments to `inout` parameters, so we only traverse down the base +// ex

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-30 Thread John McCall via cfe-commits
@@ -5915,6 +5916,16 @@ bool Sema::GatherArgumentsForCall(SourceLocation CallLoc, FunctionDecl *FDecl, ProtoArgType->isBlockPointerType()) if (auto *BE = dyn_cast(Arg->IgnoreParenNoopCasts(Context))) BE->getBlockDecl()->setDoesNotEscape(); + //

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-30 Thread John McCall via cfe-commits
@@ -5432,6 +5434,57 @@ LValue CodeGenFunction::EmitOpaqueValueLValue(const OpaqueValueExpr *e) { return getOrCreateOpaqueLValueMapping(e); } +LValue CodeGenFunction::BindHLSLOutArgExpr(const HLSLOutArgExpr *E, + Address OutTemp) { +

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-30 Thread John McCall via cfe-commits
@@ -285,6 +285,13 @@ class CallArgList : public SmallVector { /// A value to "use" after the writeback, or null. llvm::Value *ToUse; + +/// An Expression representing a cast from the temporary's type to the +/// source l-value's type. +const Expr *CastExpr;

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-30 Thread John McCall via cfe-commits
@@ -7071,6 +7071,102 @@ class ArraySectionExpr : public Expr { void setRBracketLoc(SourceLocation L) { RBracketLoc = L; } }; +/// This class represents temporary values used to represent inout and out +/// arguments in HLSL. From the callee perspective these parameters are m

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-30 Thread John McCall via cfe-commits
@@ -7071,6 +7071,102 @@ class ArraySectionExpr : public Expr { void setRBracketLoc(SourceLocation L) { RBracketLoc = L; } }; +/// This class represents temporary values used to represent inout and out +/// arguments in HLSL. From the callee perspective these parameters are m

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-30 Thread John McCall via cfe-commits
@@ -7071,6 +7071,102 @@ class ArraySectionExpr : public Expr { void setRBracketLoc(SourceLocation L) { RBracketLoc = L; } }; +/// This class represents temporary values used to represent inout and out +/// arguments in HLSL. From the callee perspective these parameters are m

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-28 Thread John McCall via cfe-commits
@@ -8511,7 +8514,7 @@ static void HandleHLSLParamModifierAttr(QualType &CurType, return; if (Attr.getSemanticSpelling() == HLSLParamModifierAttr::Keyword_inout || Attr.getSemanticSpelling() == HLSLParamModifierAttr::Keyword_out) -CurType = S.getASTContext().getL

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-28 Thread John McCall via cfe-commits
https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/101083 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-28 Thread John McCall via cfe-commits
@@ -11427,6 +11427,19 @@ static void AnalyzeImplicitConversions( return; } + if (auto *OutArgE = dyn_cast(E)) { +// The base expression is only used to initialize the parameter for +// arguments to `inout` parameters, so we only traverse down the base +// ex

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-27 Thread John McCall via cfe-commits
https://github.com/rjmccall commented: Thanks, this is looking a lot better. https://github.com/llvm/llvm-project/pull/101083 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-27 Thread John McCall via cfe-commits
@@ -5432,6 +5434,57 @@ LValue CodeGenFunction::EmitOpaqueValueLValue(const OpaqueValueExpr *e) { return getOrCreateOpaqueLValueMapping(e); } +LValue CodeGenFunction::BindHLSLOutArgExpr(const HLSLOutArgExpr *E, + Address OutTemp) { +

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-27 Thread John McCall via cfe-commits
@@ -5432,6 +5434,57 @@ LValue CodeGenFunction::EmitOpaqueValueLValue(const OpaqueValueExpr *e) { return getOrCreateOpaqueLValueMapping(e); } +LValue CodeGenFunction::BindHLSLOutArgExpr(const HLSLOutArgExpr *E, rjmccall wrote: This seems to be dead now. ht

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-27 Thread John McCall via cfe-commits
@@ -8511,7 +8514,7 @@ static void HandleHLSLParamModifierAttr(QualType &CurType, return; if (Attr.getSemanticSpelling() == HLSLParamModifierAttr::Keyword_inout || Attr.getSemanticSpelling() == HLSLParamModifierAttr::Keyword_out) -CurType = S.getASTContext().getL

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-27 Thread John McCall via cfe-commits
@@ -7061,6 +7061,67 @@ class ArraySectionExpr : public Expr { void setRBracketLoc(SourceLocation L) { RBracketLoc = L; } }; +/// This class represents temporary values used to represent inout and out +/// arguments in HLSL. From the callee perspective these parameters are mo

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-27 Thread John McCall via cfe-commits
https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/101083 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-27 Thread John McCall via cfe-commits
@@ -7071,6 +7071,93 @@ class ArraySectionExpr : public Expr { void setRBracketLoc(SourceLocation L) { RBracketLoc = L; } }; +/// This class represents temporary values used to represent inout and out +/// arguments in HLSL. From the callee perspective these parameters are mo

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-27 Thread John McCall via cfe-commits
@@ -11427,6 +11427,19 @@ static void AnalyzeImplicitConversions( return; } + if (auto *OutArgE = dyn_cast(E)) { +// The base expression is only used to initialize the parameter for +// arguments to `inout` parameters, so we only traverse down the base +// ex

[clang] Honor pragmas with -ffp-contract=fast, depecate fast-honor-pragmas (PR #105746)

2024-08-22 Thread John McCall via cfe-commits
@@ -68,35 +68,12 @@ // RUN: -O3 -target-cpu gfx906 -o - -x ir %t.ll \ // RUN: | FileCheck -check-prefixes=COMMON,AMD-OPT-FASTSTD %s -// Explicit -ffp-contract=fast-honor-pragmas -// In IR, fmul/fadd instructions with contract flag are emitted. -// In backend -//nvptx/a

[clang] Honor pragmas with -ffp-contract=fast, depecate fast-honor-pragmas (PR #105746)

2024-08-22 Thread John McCall via cfe-commits
@@ -3178,6 +3178,13 @@ static void RenderFloatingPointOptions(const ToolChain &TC, const Driver &D, StringRef Val = A->getValue(); if (Val == "fast" || Val == "on" || Val == "off" || Val == "fast-honor-pragmas") { +// fast-honor-pragmas is depreca

[clang] Honor pragmas with -ffp-contract=fast, depecate fast-honor-pragmas (PR #105746)

2024-08-22 Thread John McCall via cfe-commits
@@ -182,18 +182,8 @@ void LangOptions::setLangDefaults(LangOptions &Opts, Language Lang, Opts.HIP = Lang == Language::HIP; Opts.CUDA = Lang == Language::CUDA || Opts.HIP; - if (Opts.HIP) { -// HIP toolchain does not support 'Fast' FPOpFusion in backends since it -

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-19 Thread John McCall via cfe-commits
@@ -4148,6 +4152,30 @@ static void emitWriteback(CodeGenFunction &CGF, assert(!isProvablyNull(srcAddr.getBasePointer()) && "shouldn't have writeback for provably null argument"); + if (CGF.getLangOpts().HLSL) { +if (!isa(writeback.CastExpr)) { + RValue Tmp

[clang] [Matrix] Preserve signedness when extending matrix index expression. (PR #103044)

2024-08-16 Thread John McCall via cfe-commits
https://github.com/rjmccall approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/103044 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Matrix] Preserve signedness when extending matrix index expression. (PR #103044)

2024-08-16 Thread John McCall via cfe-commits
@@ -4348,8 +4348,18 @@ LValue CodeGenFunction::EmitMatrixSubscriptExpr(const MatrixSubscriptExpr *E) { !E->isIncomplete() && "incomplete matrix subscript expressions should be rejected during Sema"); LValue Base = EmitLValue(E->getBase()); - llvm::Value *RowIdx

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-16 Thread John McCall via cfe-commits
@@ -1121,3 +1121,99 @@ bool SemaHLSL::CheckBuiltinFunctionCall(unsigned BuiltinID, CallExpr *TheCall) { } return false; } + +bool SemaHLSL::CheckCompatibleParameterABI(FunctionDecl *New, + FunctionDecl *Old) { + if (New->getNumPar

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-15 Thread John McCall via cfe-commits
@@ -4148,6 +4152,30 @@ static void emitWriteback(CodeGenFunction &CGF, assert(!isProvablyNull(srcAddr.getBasePointer()) && "shouldn't have writeback for provably null argument"); + if (CGF.getLangOpts().HLSL) { +if (!isa(writeback.CastExpr)) { + RValue Tmp

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-15 Thread John McCall via cfe-commits
@@ -4148,6 +4152,30 @@ static void emitWriteback(CodeGenFunction &CGF, assert(!isProvablyNull(srcAddr.getBasePointer()) && "shouldn't have writeback for provably null argument"); + if (CGF.getLangOpts().HLSL) { +if (!isa(writeback.CastExpr)) { + RValue Tmp

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-15 Thread John McCall via cfe-commits
@@ -5703,6 +5709,12 @@ void CXXNameMangler::mangleExpression(const Expr *E, unsigned Arity, Out << "E"; break; } + case Expr::HLSLOutArgExprClass: { +const auto *OAE = cast(E); +Out << (OAE->isInOut() ? "_inout_" : "_out_"); +mangleType(E->getType()); +

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-15 Thread John McCall via cfe-commits
@@ -7061,6 +7061,67 @@ class ArraySectionExpr : public Expr { void setRBracketLoc(SourceLocation L) { RBracketLoc = L; } }; +/// This class represents temporary values used to represent inout and out +/// arguments in HLSL. From the callee perspective these parameters are mo

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-15 Thread John McCall via cfe-commits
@@ -4148,6 +4152,30 @@ static void emitWriteback(CodeGenFunction &CGF, assert(!isProvablyNull(srcAddr.getBasePointer()) && "shouldn't have writeback for provably null argument"); + if (CGF.getLangOpts().HLSL) { +if (!isa(writeback.CastExpr)) {

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-15 Thread John McCall via cfe-commits
@@ -7061,6 +7061,67 @@ class ArraySectionExpr : public Expr { void setRBracketLoc(SourceLocation L) { RBracketLoc = L; } }; +/// This class represents temporary values used to represent inout and out +/// arguments in HLSL. From the callee perspective these parameters are mo

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-15 Thread John McCall via cfe-commits
@@ -7061,6 +7061,67 @@ class ArraySectionExpr : public Expr { void setRBracketLoc(SourceLocation L) { RBracketLoc = L; } }; +/// This class represents temporary values used to represent inout and out +/// arguments in HLSL. From the callee perspective these parameters are mo

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-15 Thread John McCall via cfe-commits
@@ -1121,3 +1121,99 @@ bool SemaHLSL::CheckBuiltinFunctionCall(unsigned BuiltinID, CallExpr *TheCall) { } return false; } + +bool SemaHLSL::CheckCompatibleParameterABI(FunctionDecl *New, + FunctionDecl *Old) { + if (New->getNumPar

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-15 Thread John McCall via cfe-commits
@@ -4148,6 +4152,30 @@ static void emitWriteback(CodeGenFunction &CGF, assert(!isProvablyNull(srcAddr.getBasePointer()) && "shouldn't have writeback for provably null argument"); + if (CGF.getLangOpts().HLSL) { +if (!isa(writeback.CastExpr)) { + RValue Tmp

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-15 Thread John McCall via cfe-commits
@@ -4689,6 +4720,31 @@ void CodeGenFunction::EmitCallArg(CallArgList &args, const Expr *E, assert(type->isReferenceType() == E->isGLValue() && "reference binding to unmaterialized r-value!"); + // Add writeback for HLSLOutParamExpr. + if (const HLSLOutArgExpr *OE

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-15 Thread John McCall via cfe-commits
@@ -11427,6 +11427,19 @@ static void AnalyzeImplicitConversions( return; } + if (auto *OutArgE = dyn_cast(E)) { +// The base expression is only used to initialize the parameter for +// arguments to `inout` parameters, so we only traverse down the base +// ex

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-15 Thread John McCall via cfe-commits
@@ -7061,6 +7061,67 @@ class ArraySectionExpr : public Expr { void setRBracketLoc(SourceLocation L) { RBracketLoc = L; } }; +/// This class represents temporary values used to represent inout and out +/// arguments in HLSL. From the callee perspective these parameters are mo

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-15 Thread John McCall via cfe-commits
@@ -4689,6 +4720,31 @@ void CodeGenFunction::EmitCallArg(CallArgList &args, const Expr *E, assert(type->isReferenceType() == E->isGLValue() && "reference binding to unmaterialized r-value!"); + // Add writeback for HLSLOutParamExpr. + if (const HLSLOutArgExpr *OE

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-15 Thread John McCall via cfe-commits
@@ -1121,3 +1121,99 @@ bool SemaHLSL::CheckBuiltinFunctionCall(unsigned BuiltinID, CallExpr *TheCall) { } return false; } + +bool SemaHLSL::CheckCompatibleParameterABI(FunctionDecl *New, + FunctionDecl *Old) { + if (New->getNumPar

[clang] [HLSL] Implement output parameter (PR #101083)

2024-08-15 Thread John McCall via cfe-commits
https://github.com/rjmccall requested changes to this pull request. https://github.com/llvm/llvm-project/pull/101083 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Matrix] Preserve signedness when extending matrix index expression. (PR #103044)

2024-08-15 Thread John McCall via cfe-commits
@@ -4348,8 +4348,18 @@ LValue CodeGenFunction::EmitMatrixSubscriptExpr(const MatrixSubscriptExpr *E) { !E->isIncomplete() && "incomplete matrix subscript expressions should be rejected during Sema"); LValue Base = EmitLValue(E->getBase()); - llvm::Value *RowIdx

[clang] [Matrix] Preserve signedness when extending matrix index expression. (PR #103044)

2024-08-15 Thread John McCall via cfe-commits
@@ -4348,8 +4348,18 @@ LValue CodeGenFunction::EmitMatrixSubscriptExpr(const MatrixSubscriptExpr *E) { !E->isIncomplete() && "incomplete matrix subscript expressions should be rejected during Sema"); LValue Base = EmitLValue(E->getBase()); - llvm::Value *RowIdx

[clang] [Matrix] Preserve signedness when extending matrix index expression. (PR #103044)

2024-08-13 Thread John McCall via cfe-commits
rjmccall wrote: Do you just want whatever the logic is for array subscripts? I believe array subscripts technically leave the index unconverted, and then we perform the necessary conversion when emitting IR. https://github.com/llvm/llvm-project/pull/103044

[clang] [llvm] [IR] Add method to GlobalVariable to change type of initializer. (PR #102553)

2024-08-08 Thread John McCall via cfe-commits
https://github.com/rjmccall approved this pull request. Well, this is wonderful, thank you. LGTM. https://github.com/llvm/llvm-project/pull/102553 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/c

[clang] [clang][CodeGen] Zero init unspecified fields in initializers in C (PR #97121)

2024-08-01 Thread John McCall via cfe-commits
@@ -361,6 +368,13 @@ CodeGenFunction::AddInitializerToStaticVarDecl(const VarDecl &D, } return GV; } + if (!getLangOpts().CPlusPlus) { +// In C, when an initializer is given, the Linux kernel relies on clang to +// zero-initialize all members not explicitly

[clang] [clang][CodeGen] Zero init unspecified fields in initializers in C (PR #97121)

2024-08-01 Thread John McCall via cfe-commits
@@ -361,6 +368,13 @@ CodeGenFunction::AddInitializerToStaticVarDecl(const VarDecl &D, } return GV; } + if (!getLangOpts().CPlusPlus) { +// In C, when an initializer is given, the Linux kernel relies on clang to +// zero-initialize all members not explicitly

[clang] [llvm] [Clang] Fix definition of layout-compatible to ignore empty classes (PR #92103)

2024-07-31 Thread John McCall via cfe-commits
@@ -160,6 +160,9 @@ Bug Fixes in This Version Bug Fixes to Compiler Builtins ^^ +- ``__is_layout_compatible`` no longer requires the empty bases to be the same in two + standard-layout classes. It now only compares non-static data members. ---

[clang] [llvm] [Clang] Fix definition of layout-compatible to ignore empty classes (PR #92103)

2024-07-31 Thread John McCall via cfe-commits
@@ -160,6 +160,9 @@ Bug Fixes in This Version Bug Fixes to Compiler Builtins ^^ +- ``__is_layout_compatible`` no longer requires the empty bases to be the same in two + standard-layout classes. It now only compares non-static data members. ---

[clang] [llvm] [Clang] Fix definition of layout-compatible to ignore empty classes (PR #92103)

2024-07-31 Thread John McCall via cfe-commits
https://github.com/rjmccall commented: The code changes look right to me. https://github.com/llvm/llvm-project/pull/92103 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [Clang] Fix definition of layout-compatible to ignore empty classes (PR #92103)

2024-07-31 Thread John McCall via cfe-commits
https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/92103 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][CodeGen] The linux kernel expects initializers to FULLY initialize variables, structs and unions including padding (PR #97121)

2024-07-31 Thread John McCall via cfe-commits
@@ -361,6 +368,13 @@ CodeGenFunction::AddInitializerToStaticVarDecl(const VarDecl &D, } return GV; } + if (!getLangOpts().CPlusPlus) { +// In C, when an initializer is given, the Linux kernel relies on clang to +// zero-initialize all members not explicitly

[clang] [clang][CodeGen] The linux kernel expects initializers to FULLY initialize variables, structs and unions including padding (PR #97121)

2024-07-31 Thread John McCall via cfe-commits
@@ -361,6 +368,13 @@ CodeGenFunction::AddInitializerToStaticVarDecl(const VarDecl &D, } return GV; } + if (!getLangOpts().CPlusPlus) { +// In C, when an initializer is given, the Linux kernel relies on clang to +// zero-initialize all members not explicitly

[clang] [clang][CodeGen] The linux kernel expects initializers to FULLY initialize variables, structs and unions including padding (PR #97121)

2024-07-31 Thread John McCall via cfe-commits
https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/97121 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][CodeGen] The linux kernel expects initializers to FULLY initialize variables, structs and unions including padding (PR #97121)

2024-07-31 Thread John McCall via cfe-commits
https://github.com/rjmccall commented: Is this really all that's required? It looks like you're just filling in explicit zero padding when emitting constant initializers. That should steer clear of any possibility that LLVM would treat the padding as `undef` for optimization purposes (surely

[clang] [C] Disable use of NRVO (PR #101038)

2024-07-29 Thread John McCall via cfe-commits
rjmccall wrote: > Should we try to convince at least the GCC folks that they're getting this > wrong too? It does feel like a wider conversation is necessary, yeah. The fact that everybody is doing this even on x86_64 where it's pretty incontrovertibly forbidden seems significant. https://g

[clang] [C] Disable use of NRVO (PR #101038)

2024-07-29 Thread John McCall via cfe-commits
rjmccall wrote: > > C++ does have some restrictions on accessing objects that are being > > initialized through other names. It's possible that they're strong enough > > to satisfy the ABI rule here through a sort of reverse of the normal > > analysis: basically, any program that would violate

[clang] [C] Disable use of NRVO (PR #101038)

2024-07-29 Thread John McCall via cfe-commits
rjmccall wrote: I accept your pedantry. 🫡 > Do we support ABIs that don't have a rule like x86_64's? The ARM and ARM64 AAPCSs specify that "The memory to be used for the result may be modified at any point during the function call" and "The callee may modify the result memory block at any po

[clang] [C] Disable use of NRVO (PR #101038)

2024-07-29 Thread John McCall via cfe-commits
rjmccall wrote: My argument above is that the x86-64 psABI requires us to not pass `&t` as the indirect return address. Following that rule fixes the problem here even if we keep doing NRVO. I think the approximate shape of the correct fix here is to: (1) Use the function Eli pointed out to c

[clang] [C] Disable use of NRVO (PR #101038)

2024-07-29 Thread John McCall via cfe-commits
rjmccall wrote: Note that we're forced to override that ABI rule in C++ sometimes — I believe we're now required (since C++11?) to elide a copy/move when initializing a normal object with a return value, and even if we weren't, it'd clearly be unreasonable compiler behavior to do an extra non-

[clang] [C] Disable use of NRVO (PR #101038)

2024-07-29 Thread John McCall via cfe-commits
https://github.com/rjmccall requested changes to this pull request. We shouldn't merge this PR unless we need an immediate fix, which seems unlikely given how longstanding this behavior is. https://github.com/llvm/llvm-project/pull/101038 ___ cfe-comm

[clang] [C] Disable use of NRVO (PR #101038)

2024-07-29 Thread John McCall via cfe-commits
rjmccall wrote: I agree that the standard does not appear to permit this in C. There are three ways to fix this: 1. Disable NRVO in the callee just in case the address being initialized is aliased. 2. Disable RVO in the caller when aliasing is possible. 3. Convince the committee that they shou

[clang] [clang] Generate nuw GEPs for struct member accesses (PR #99538)

2024-07-25 Thread John McCall via cfe-commits
rjmccall wrote: `CGBuilder` is just aiming to provide an `Address` overload of LLVM's `CreateStructGEP`. It seems wrong for two overloads to have subtly different behavior. Is there a reason why LLVM's `CreateStructGEP` doesn't add `nuw` itself? https://github.com/llvm/llvm-project/pull/9953

[clang] [PAC] Implement authentication for C++ member function pointers (PR #99576)

2024-07-22 Thread John McCall via cfe-commits
@@ -1036,9 +1155,32 @@ llvm::Constant *ItaniumCXXABI::BuildMemberPointer(const CXXMethodDecl *MD, // least significant bit of adj then makes exactly the same // discrimination as the least significant bit of ptr does for // Itanium. - MemPtr[0] = l

[clang] [Clang][CodeGen] Add metadata for load from reference (PR #98746)

2024-07-22 Thread John McCall via cfe-commits
https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/98746 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][CodeGen] Add metadata for load from reference (PR #98746)

2024-07-22 Thread John McCall via cfe-commits
@@ -2799,9 +2799,37 @@ CodeGenFunction::EmitLoadOfReference(LValue RefLVal, llvm::LoadInst *Load = Builder.CreateLoad(RefLVal.getAddress(), RefLVal.isVolatile()); CGM.DecorateInstructionWithTBAA(Load, RefLVal.getTBAAInfo()); - return makeNaturalAddressForPointer(Load

[clang] [Sema] Don't drop weak_import from a declaration that follows a declaration directly contained in a linkage-specification (PR #85886)

2024-07-17 Thread John McCall via cfe-commits
https://github.com/rjmccall approved this pull request. https://github.com/llvm/llvm-project/pull/85886 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Sema] Don't drop weak_import from a declaration that follows a declaration directly contained in a linkage-specification (PR #85886)

2024-07-17 Thread John McCall via cfe-commits
https://github.com/rjmccall approved this pull request. LGTM. The (existing) diagnostic wording does seem a little awkward, so if you want to put effort into cleaning that up, it'd be welcome, but I won't hold up this fix. https://github.com/llvm/llvm-project/pull/85886 __

[clang] [clang][NFC] Move more functions from `Sema` to `SemaObjC` (PR #97172)

2024-07-16 Thread John McCall via cfe-commits
rjmccall wrote: I agree that blocks don't belong in the ObjC segment. https://github.com/llvm/llvm-project/pull/97172 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Use different memory layout type for _BitInt(N) in LLVM IR (PR #91364)

2024-07-12 Thread John McCall via cfe-commits
https://github.com/rjmccall approved this pull request. https://github.com/llvm/llvm-project/pull/91364 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Use different memory layout type for _BitInt(N) in LLVM IR (PR #91364)

2024-07-12 Thread John McCall via cfe-commits
rjmccall wrote: > > Okay, so x86_64 describes it in byte terms and says they're little-endian, > > which is consistent with the overall target. Interestingly, it does not > > guarantee the content of the excess bits. The code-generation in this patch > > is consistent with that: the extension

[clang] [C2y] Add documentation to conform to WG14 N3262; NFC (PR #98146)

2024-07-11 Thread John McCall via cfe-commits
https://github.com/rjmccall approved this pull request. https://github.com/llvm/llvm-project/pull/98146 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

2024-07-11 Thread John McCall via cfe-commits
rjmccall wrote: Given all that, I feel pretty comfortable relying on using LLVM's `i96` stores and so on. I do worry some that we're eventually going to run into a target where the `_BitInt` ABI does not match what LLVM wants to generate for `i96` load/store, but we should be able to generali

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

2024-07-11 Thread John McCall via cfe-commits
rjmccall wrote: Okay, so x86_64 describes it in byte terms and says they're little-endian, which is consistent with the overall target. Interestingly, it does not guarantee the content of the excess bits. The code-generation in this patch is consistent with that: the extension we do is unnec

[clang] [C2y] Add documentation to conform to WG14 N3262; NFC (PR #98146)

2024-07-10 Thread John McCall via cfe-commits
rjmccall wrote: Ah right, I'd forgotten that some ABIs use that array trick to get it to pass by reference, and you're right that that makes it ill-formed to simply assign around. I like your idea of specifically making it UB to copy with `memcpy` etc and just advising that people use va_copy

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

2024-07-10 Thread John McCall via cfe-commits
https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/91364 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

2024-07-10 Thread John McCall via cfe-commits
https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/91364 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

2024-07-10 Thread John McCall via cfe-commits
@@ -89,7 +89,7 @@ void CodeGenTypes::addRecordTypeName(const RecordDecl *RD, /// ConvertType in that it is used to convert to the memory representation for /// a type. For example, the scalar representation for _Bool is i1, but the /// memory representation is usually i8 or i3

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

2024-07-10 Thread John McCall via cfe-commits
@@ -107,17 +107,52 @@ llvm::Type *CodeGenTypes::ConvertTypeForMem(QualType T, bool ForBitField) { return llvm::IntegerType::get(FixedVT->getContext(), BytePadded); } - // If this is a bool type, or a bit-precise integer type in a bitfield - // representation, map this

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

2024-07-10 Thread John McCall via cfe-commits
https://github.com/rjmccall commented: This is generally looking great, and I think it's ready to go as soon as you can finish the tests. (You said you weren't able to update all the tests — did you have questions about the remaining tests?) I did have a thought, though. Are we confident that

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

2024-07-10 Thread John McCall via cfe-commits
https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/91364 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

2024-07-10 Thread John McCall via cfe-commits
@@ -1886,6 +1896,29 @@ llvm::Constant *ConstantEmitter::emitForMemory(CodeGenModule &CGM, return Res; } + if (destType->isBitIntType()) { +if (CGM.getTypes().typeRequiresSplitIntoByteArray(destType, C->getType())) { + // Long _BitInt has array of bytes as in-

[clang] [C2y] Add documentation to conform to WG14 N3262; NFC (PR #98146)

2024-07-10 Thread John McCall via cfe-commits
rjmccall wrote: Oh, I completely spaced on this before, but of course there *are* constraints on `va_list` in the standard: `va_list`s are passed by value to functions like `vprintf`. That, of course, requires the value to be primitively copied. If you call `vprintf(format, args)`, the standa

[clang] [C2y] Add documentation to conform to WG14 N3262; NFC (PR #98146)

2024-07-09 Thread John McCall via cfe-commits
rjmccall wrote: > > _Every_ `va_list` stores pointers; otherwise, it wouldn't be able to > > support an arbitrary number of arguments. Copying just copies the pointers, > > and that's fine because the memory they point to is immutable and always > > outlives the `va_list`. You can imagine a `v

[clang] [C2y] Add documentation to conform to WG14 N3262; NFC (PR #98146)

2024-07-09 Thread John McCall via cfe-commits
rjmccall wrote: *Every* `va_list` stores pointers; otherwise, it wouldn't be able to support an arbitrary number of arguments. Copying just copies the pointers, and that's fine because the memory they point to is immutable and always outlives the `va_list`. You can imagine a `va_list` implem

[clang] [C2y] Add documentation to conform to WG14 N3262; NFC (PR #98146)

2024-07-09 Thread John McCall via cfe-commits
rjmccall wrote: I also have trouble imagining why a target would ever want to make `va_copy` a non-trivial operation, and I suspect that in practice programmers do not reliably call `va_end` to clean up their iterations. In general, I would say that platforms should be moving towards making v

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

2024-07-09 Thread John McCall via cfe-commits
@@ -2093,17 +2107,10 @@ void CodeGenFunction::EmitStoreOfScalar(llvm::Value *Value, Address Addr, llvm::Type *SrcTy = Value->getType(); if (const auto *ClangVecTy = Ty->getAs()) { auto *VecTy = dyn_cast(SrcTy); -if (VecTy && ClangVecTy->isExtVectorBoolType()) { -

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

2024-07-09 Thread John McCall via cfe-commits
@@ -1774,6 +1774,18 @@ llvm::Constant *ConstantEmitter::emitForMemory(CodeGenModule &CGM, return Res; } + if (const auto *BIT = destType->getAs()) { +if (BIT->getNumBits() > 128) { + // Long _BitInt has array of bytes as in-memory type. + ConstantAggregat

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

2024-07-09 Thread John McCall via cfe-commits
@@ -1,12 +1,25 @@ -// RUN: %clang_cc1 -triple x86_64-gnu-linux -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=CHECK,CHECK64 -// RUN: %clang_cc1 -triple x86_64-windows-pc -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=CHEC

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

2024-07-09 Thread John McCall via cfe-commits
@@ -609,9 +609,25 @@ bool ConstStructBuilder::AppendBytes(CharUnits FieldOffsetInChars, return Builder.add(InitCst, StartOffset + FieldOffsetInChars, AllowOverwrite); } -bool ConstStructBuilder::AppendBitField( -const FieldDecl *Field, uint64_t FieldOffset, llvm::Const

[clang] [clang] Implement function pointer type discrimination (PR #96992)

2024-07-08 Thread John McCall via cfe-commits
@@ -3140,6 +3140,269 @@ ASTContext::getPointerAuthVTablePointerDiscriminator(const CXXRecordDecl *RD) { return llvm::getPointerAuthStableSipHash(Str); } +/// Encode a function type for use in the discriminator of a function pointer +/// type. We can't use the itanium scheme

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

2024-07-08 Thread John McCall via cfe-commits
@@ -1774,6 +1784,22 @@ llvm::Constant *ConstantEmitter::emitForMemory(CodeGenModule &CGM, return Res; } + if (destType->isBitIntType()) { +if (!CGM.getTypes().LLVMTypeLayoutMatchesAST(destType, C->getType())) { + // Long _BitInt has array of bytes as in-memory

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

2024-07-08 Thread John McCall via cfe-commits
https://github.com/rjmccall requested changes to this pull request. Getting very close. https://github.com/llvm/llvm-project/pull/91364 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

2024-07-08 Thread John McCall via cfe-commits
@@ -118,6 +124,39 @@ llvm::Type *CodeGenTypes::ConvertTypeForMem(QualType T, bool ForBitField) { return R; } +bool CodeGenTypes::typeRequiresSplitIntoByteArray(QualType ASTTy, + llvm::Type *LLVMTy) { + if (!LLVMTy) +LLVM

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

2024-07-08 Thread John McCall via cfe-commits
https://github.com/rjmccall edited https://github.com/llvm/llvm-project/pull/91364 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

  1   2   3   4   5   6   7   8   9   >