[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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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] [PAC][clang] Define `PointerAuthQualifier` and `PointerAuthenticationMode` (PR #84384)

2024-04-08 Thread John McCall via cfe-commits
rjmccall wrote: It'll be tested in a follow-up commit which actually adds parsing and Sema support for these as qualifiers. That should be sufficient rather than adding a whole unit-test apparatus. Daniil is just trying to avoid landing this in a single massive commit. https://github.com/ll

[clang] [Clang][CodeGen] Start migrating away from assuming the Default AS is 0 (PR #88182)

2024-04-09 Thread John McCall via cfe-commits
rjmccall wrote: It's very uncommon for LLVM to need to come up with an address space on its own, as opposed to just propagating the original address space of some memory / operation as chosen by the frontend. LLVM occasionally creates new storage allocations, but usually they're (non-escaping

[clang] [Clang][CodeGen] Start migrating away from assuming the Default AS is 0 (PR #88182)

2024-04-09 Thread John McCall via cfe-commits
rjmccall wrote: > Why can't we just declare that the "generic" address-space must always be 0? > The specific numbers we use for address-spaces are completely arbitrary > anyway. I don't think this works; there's nothing that LLVM could possibly do with a generic AS that would justify it bein

[clang] [Clang][CodeGen] Start migrating away from assuming the Default AS is 0 (PR #88182)

2024-04-09 Thread John McCall via cfe-commits
rjmccall wrote: > I'm not quite sure how to parse this comment, could you explain what you have > in mind here? The problem is precisely that the FE assumes 0 is fine / picks > it by default, which ends up into dangerzones when e.g. a target happened to > use 0 to point to private (stack). I f

[clang] [Clang][CodeGen] Start migrating away from assuming the Default AS is 0 (PR #88182)

2024-04-09 Thread John McCall via cfe-commits
rjmccall wrote: > Libcall emission needs to know what AS to use for pointer arguments to things > like __sync/__atomic implementations and various string-y mem*/str* > functions. That's the main one that comes to mind from our experience in > CHERI LLVM, and current LLVM just assumes that's AS

[clang] [Clang][CodeGen] Start migrating away from assuming the Default AS is 0 (PR #88182)

2024-04-09 Thread John McCall via cfe-commits
@@ -2216,7 +2216,7 @@ static llvm::Value *EmitTypeidFromVTable(CodeGenFunction &CGF, const Expr *E, } llvm::Value *CodeGenFunction::EmitCXXTypeidExpr(const CXXTypeidExpr *E) { - llvm::Type *PtrTy = llvm::PointerType::getUnqual(getLLVMContext()); + llvm::Type *PtrTy = Int8Pt

[clang] [PAC][clang] Define `PointerAuthQualifier` and `PointerAuthenticationMode` (PR #84384)

2024-04-12 Thread John McCall via cfe-commits
rjmccall wrote: It's my patch, so me signing off isn't very meaningful. https://github.com/llvm/llvm-project/pull/84384 ___ 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-06-05 Thread John McCall via cfe-commits
@@ -118,6 +124,37 @@ llvm::Type *CodeGenTypes::ConvertTypeForMem(QualType T, bool ForBitField) { return R; } +bool CodeGenTypes::LLVMTypeLayoutMatchesAST(QualType ASTTy, +llvm::Type *LLVMTy) { + CharUnits ASTSize = Context.getTyp

[clang] [clang][CodeGen] Return RValue from `EmitVAArg` (PR #94635)

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

[clang] [clang][CodeGen] Return RValue from `EmitVAArg` (PR #94635)

2024-06-06 Thread John McCall via cfe-commits
@@ -1328,15 +1328,15 @@ void AggExprEmitter::VisitChooseExpr(const ChooseExpr *CE) { void AggExprEmitter::VisitVAArgExpr(VAArgExpr *VE) { Address ArgValue = Address::invalid(); - Address ArgPtr = CGF.EmitVAArg(VE, ArgValue); + RValue ArgPtr = CGF.EmitVAArg(VE, ArgValue);

[clang] [clang][CodeGen] Return RValue from `EmitVAArg` (PR #94635)

2024-06-06 Thread John McCall via cfe-commits
@@ -5988,12 +5988,29 @@ CGCallee CGCallee::prepareConcreteCallee(CodeGenFunction &CGF) const { /* VarArg handling */ -Address CodeGenFunction::EmitVAArg(VAArgExpr *VE, Address &VAListAddr) { - VAListAddr = VE->isMicrosoftABI() - ? EmitMSVAListRef(VE->getSubE

[clang] [clang][CodeGen] Return RValue from `EmitVAArg` (PR #94635)

2024-06-06 Thread John McCall via cfe-commits
https://github.com/rjmccall commented: I was hoping that you might push this down into the target code — if you make `emitVoidPtrVAArg` return an `RValue`, that'll handle about half of the targets. Most of the rest will just need an `EmitLoadOfLValue` at the end. MIPS (which is the target wi

[clang] [clang][CodeGen] Return RValue from `EmitVAArg` (PR #94635)

2024-06-07 Thread John McCall via cfe-commits
rjmccall wrote: > > I was hoping that you might push this down into the target code — if you > > make emitVoidPtrVAArg return an RValue, that'll handle about half of the > > targets. Most of the rest will just need an EmitLoadOfLValue at the end > > Ok, that seems doable, but I'm having troubl

[clang] [clang][CodeGen] Return RValue from `EmitVAArg` (PR #94635)

2024-06-07 Thread John McCall via cfe-commits
@@ -1328,15 +1328,15 @@ void AggExprEmitter::VisitChooseExpr(const ChooseExpr *CE) { void AggExprEmitter::VisitVAArgExpr(VAArgExpr *VE) { Address ArgValue = Address::invalid(); - Address ArgPtr = CGF.EmitVAArg(VE, ArgValue); + RValue ArgPtr = CGF.EmitVAArg(VE, ArgValue);

[clang] [CodeGen] Simplify codegen for array initialization (PR #93956)

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

[clang] [ObjC][CodeGen] Assume a for-in loop is in bounds and cannot overflow (PR #94885)

2024-06-10 Thread John McCall via cfe-commits
https://github.com/rjmccall commented: LGTM. Do we not have any tests that actually test the add? https://github.com/llvm/llvm-project/pull/94885 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/c

[clang] [clang][CodeGen] Return RValue from `EmitVAArg` (PR #94635)

2024-06-10 Thread John McCall via cfe-commits
@@ -2161,6 +2161,19 @@ static RValue EmitLoadOfMatrixLValue(LValue LV, SourceLocation Loc, return RValue::get(CGF.EmitLoadOfScalar(LV, Loc)); } +RValue CodeGenFunction::EmitLoadOfAnyValue(LValue LV, SourceLocation Loc) { + QualType Ty = LV.getType(); + switch (getEvaluati

[clang] [clang][CodeGen] Return RValue from `EmitVAArg` (PR #94635)

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

[clang] [clang][CodeGen] Return RValue from `EmitVAArg` (PR #94635)

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

[clang] [clang][CodeGen] Return RValue from `EmitVAArg` (PR #94635)

2024-06-11 Thread John McCall via cfe-commits
@@ -2161,6 +2161,21 @@ static RValue EmitLoadOfMatrixLValue(LValue LV, SourceLocation Loc, return RValue::get(CGF.EmitLoadOfScalar(LV, Loc)); } +RValue CodeGenFunction::EmitLoadOfAnyValue(LValue LV, AggValueSlot Slot, + SourceLocati

[clang] [clang][CodeGen] Return RValue from `EmitVAArg` (PR #94635)

2024-06-11 Thread John McCall via cfe-commits
https://github.com/rjmccall commented: Other than the one slight nit (that I think may be irrelevant), this LGTM. I'd like @efriedma-quic to also do a quick review if he has time, though. https://github.com/llvm/llvm-project/pull/94635 ___ cfe-commit

[clang] [clang][CodeGen] Return RValue from `EmitVAArg` (PR #94635)

2024-06-11 Thread John McCall via cfe-commits
@@ -789,27 +791,37 @@ Address AArch64ABIInfo::EmitAAPCSVAArg(Address VAListAddr, QualType Ty, OnStackBlock, "vaargs.addr"); if (IsIndirect) -return Address(CGF.Builder.CreateLoad(ResAddr, "vaarg.addr"), ElementTy, - TyA

[clang] [clang][CodeGen] Return RValue from `EmitVAArg` (PR #94635)

2024-06-11 Thread John McCall via cfe-commits
@@ -789,27 +791,37 @@ Address AArch64ABIInfo::EmitAAPCSVAArg(Address VAListAddr, QualType Ty, OnStackBlock, "vaargs.addr"); if (IsIndirect) -return Address(CGF.Builder.CreateLoad(ResAddr, "vaarg.addr"), ElementTy, - TyA

[clang] [clang][CodeGen] Return RValue from `EmitVAArg` (PR #94635)

2024-06-12 Thread John McCall via cfe-commits
@@ -325,14 +325,19 @@ Address SparcV9ABIInfo::EmitVAArg(CodeGenFunction &CGF, Address VAListAddr, break; case ABIArgInfo::Ignore: -return Address(llvm::UndefValue::get(ArgPtrTy), ArgTy, TypeInfo.Align); +return CGF.EmitLoadOfAnyValue( +CGF.MakeAddrLValue

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

2024-06-12 Thread John McCall via cfe-commits
@@ -1533,9 +1533,17 @@ void CodeGenFunction::EmitReturnStmt(const ReturnStmt &S) { Builder.CreateStore(Result.getScalarVal(), ReturnValue); } else { switch (getEvaluationKind(RV->getType())) { -case TEK_Scalar: - Builder.CreateStore(EmitScalarExpr(RV), Retur

[clang] [Clang] Fix potential null pointer dereferences in retain cycle detection (PR #95192)

2024-06-14 Thread John McCall via cfe-commits
rjmccall wrote: Do you have a test case? https://github.com/llvm/llvm-project/pull/95192 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Fix potential null pointer dereferences in retain cycle detection (PR #95192)

2024-06-14 Thread John McCall via cfe-commits
https://github.com/rjmccall closed https://github.com/llvm/llvm-project/pull/95192 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Fix potential null pointer dereferences in retain cycle detection (PR #95192)

2024-06-14 Thread John McCall via cfe-commits
rjmccall wrote: Okay. It looks like it's actually impossible for this to be null — since we're looking at a `super` dispatch, we must be inside an Objective-C method declaration. We do appreciate people running static analysis on our code base, but please think of analysis reports as the sta

[clang] [clang] fix the unexpected controlflow in `ParseTentative.cpp` (PR #95917)

2024-06-18 Thread John McCall via cfe-commits
rjmccall wrote: > @rjmccall -- do you have ideas on how we can trigger the issue here or do you > think this code can be removed? I wouldn't be surprised either way — tentative parsing often contains code that feels like it ought to be redundant, but it also often takes strange paths in stran

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

2024-06-20 Thread John McCall via cfe-commits
@@ -118,6 +124,37 @@ llvm::Type *CodeGenTypes::ConvertTypeForMem(QualType T, bool ForBitField) { return R; } +bool CodeGenTypes::LLVMTypeLayoutMatchesAST(QualType ASTTy, +llvm::Type *LLVMTy) { + CharUnits ASTSize = Context.getTyp

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

2024-06-20 Thread John McCall via cfe-commits
@@ -2012,26 +2015,27 @@ llvm::Value *CodeGenFunction::EmitLoadOfScalar(Address Addr, bool Volatile, } llvm::Value *CodeGenFunction::EmitToMemory(llvm::Value *Value, QualType Ty) { - // Bool has a different representation in memory than in registers. - if (hasBooleanRepresen

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

2024-05-29 Thread John McCall via cfe-commits
rjmccall wrote: Changing a type trait is generally always an ABI problem, but yeah, if this hasn't been released yet, we're still free to fix basic bugs. https://github.com/llvm/llvm-project/pull/92103 ___ cfe-commits mailing list cfe-commits@lists.ll

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

2024-05-29 Thread John McCall via cfe-commits
@@ -2012,26 +2015,27 @@ llvm::Value *CodeGenFunction::EmitLoadOfScalar(Address Addr, bool Volatile, } llvm::Value *CodeGenFunction::EmitToMemory(llvm::Value *Value, QualType Ty) { - // Bool has a different representation in memory than in registers. - if (hasBooleanRepresen

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

2024-05-29 Thread John McCall via cfe-commits
@@ -2012,26 +2015,27 @@ llvm::Value *CodeGenFunction::EmitLoadOfScalar(Address Addr, bool Volatile, } llvm::Value *CodeGenFunction::EmitToMemory(llvm::Value *Value, QualType Ty) { rjmccall wrote: ```suggestion /// Converts a scalar value from its primary IR

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

2024-05-29 Thread John McCall via cfe-commits
@@ -2044,6 +2048,12 @@ llvm::Value *CodeGenFunction::EmitFromMemory(llvm::Value *Value, QualType Ty) { return emitBoolVecConversion(V, ValNumElems, "extractvec"); } + if (hasBooleanRepresentation(Ty) || Ty->isBitIntType()) { +llvm::Type *ResTy = ConvertType(Ty); +

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

2024-05-29 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-05-29 Thread John McCall via cfe-commits
@@ -5348,18 +5348,8 @@ Value *ScalarExprEmitter::VisitVAArgExpr(VAArgExpr *VE) { return llvm::UndefValue::get(ArgTy); } - // FIXME Volatility. - llvm::Value *Val = Builder.CreateLoad(ArgPtr); - - // If EmitVAArg promoted the type, we must truncate it. - if (ArgTy !=

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

2024-05-29 Thread John McCall via cfe-commits
@@ -1533,9 +1533,17 @@ void CodeGenFunction::EmitReturnStmt(const ReturnStmt &S) { Builder.CreateStore(Result.getScalarVal(), ReturnValue); } else { switch (getEvaluationKind(RV->getType())) { -case TEK_Scalar: - Builder.CreateStore(EmitScalarExpr(RV), Retur

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

2024-05-29 Thread John McCall via cfe-commits
@@ -2012,26 +2015,27 @@ llvm::Value *CodeGenFunction::EmitLoadOfScalar(Address Addr, bool Volatile, } llvm::Value *CodeGenFunction::EmitToMemory(llvm::Value *Value, QualType Ty) { - // Bool has a different representation in memory than in registers. - if (hasBooleanRepresen

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

2024-05-30 Thread John McCall via cfe-commits
@@ -5348,18 +5348,8 @@ Value *ScalarExprEmitter::VisitVAArgExpr(VAArgExpr *VE) { return llvm::UndefValue::get(ArgTy); } - // FIXME Volatility. - llvm::Value *Val = Builder.CreateLoad(ArgPtr); - - // If EmitVAArg promoted the type, we must truncate it. - if (ArgTy !=

[clang] [lldb] [clang][lldb] Don't assert structure layout correctness for layouts provided by LLDB (PR #93809)

2024-05-30 Thread John McCall via cfe-commits
rjmccall wrote: I agree with Eli. We should trust external record layout to the extent that it generates a valid layout, but if it generates something with overlapping fields, or that runs outside the claimed bounds of the type, we'll just end up crashing in IRGen. I assume those things are

[clang] [compiler-rt] [ubsan] Display correct runtime messages for negative _BitInt (PR #93612)

2024-05-31 Thread John McCall via cfe-commits
@@ -64,6 +65,20 @@ static llvm::cl::opt ClSanitizeGuardChecks( "ubsan-guard-checks", llvm::cl::Optional, llvm::cl::desc("Guard UBSAN checks with `llvm.allow.ubsan.check()`.")); +//======// +//

[clang] [clang] Move tailclipping to bitfield allocation (PR #87090)

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

[clang] [clang-tools-extra] [PAC][clang] Define `PointerAuthQualifier` and `PointerAuthenticationMode` (PR #84384)

2024-04-18 Thread John McCall via cfe-commits
rjmccall wrote: > > @AaronBallman See test results from compile-time-tracker here: > > https://llvm-compile-time-tracker.com/compare.php?from=693a458287d019c5c6a66fe3019d099df2978cdb&to=dbb5e29d136a18060ba6759b328ad80fa9cea649. > > It looks like that there is a statistically meaningful differenc

[clang] [clang-tools-extra] [PAC][clang] Define `PointerAuthQualifier` and `PointerAuthenticationMode` (PR #84384)

2024-04-22 Thread John McCall via cfe-commits
rjmccall wrote: > Ah, okay, thank you! I had two concerns, but I think neither are valid now > that I better understand how `ExtQuals` works: 1) I thought we were > increasing the in-memory size of `Qualifiers` in a way that matter (like > `SplitQualType`, `ExtProtoInfo` primarily), AFAIK, `S

[clang] Fix objc_sel_{name,types} missing an underscore (PR #88713)

2024-04-22 Thread John McCall via cfe-commits
https://github.com/rjmccall commented: At first, I was worried that this was an ABI break. Then I noticed the internal inconsistency within this single file, and so I became worried that it was an ABI *fix*. But then I noticed that the normal selector-emission code actually makes these strin

[clang] Fix objc_sel_{name,types} missing an underscore (PR #88713)

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

[clang] [clang] Set correct FPOptions if attribute 'optnone' presents (PR #85605)

2024-04-22 Thread John McCall via cfe-commits
https://github.com/rjmccall approved this pull request. This seems fine. Is there any existing bookkeeping we no longer need to do if we're going to have this RAII object in scope during function parsing? https://github.com/llvm/llvm-project/pull/85605 _

[clang] Fix objc_sel_{name,types} missing an underscore (PR #88713)

2024-04-22 Thread John McCall via cfe-commits
rjmccall wrote: Great, thanks! @Midar, if you can fix this code up so that these strings are created in one place (and test the new output, since this is not NFC), I'd be happy to sign off. https://github.com/llvm/llvm-project/pull/88713 ___ cfe-com

[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] [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] [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: 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
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: 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: > > 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: > 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] [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] [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] [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] [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] [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] [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] Perform derived-to-base conversion on explicit object parameter in lambda (PR #89828)

2024-04-23 Thread John McCall via cfe-commits
@@ -4684,6 +4684,29 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const FieldDecl *Field, else LambdaLV = MakeAddrLValue(AddrOfExplicitObject, D->getType().getNonReferenceType()); + +// Make sure we have an lvalue to the lamb

[clang] [Clang] [CodeGen] Perform derived-to-base conversion on explicit object parameter in lambda (PR #89828)

2024-04-23 Thread John McCall via cfe-commits
@@ -4684,6 +4684,29 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const FieldDecl *Field, else LambdaLV = MakeAddrLValue(AddrOfExplicitObject, D->getType().getNonReferenceType()); + +// Make sure we have an lvalue to the lamb

[clang] [Clang] [CodeGen] Perform derived-to-base conversion on explicit object parameter in lambda (PR #89828)

2024-04-24 Thread John McCall via cfe-commits
@@ -4684,6 +4684,29 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const FieldDecl *Field, else LambdaLV = MakeAddrLValue(AddrOfExplicitObject, D->getType().getNonReferenceType()); + +// Make sure we have an lvalue to the lamb

[clang] [Clang] [CodeGen] Perform derived-to-base conversion on explicit object parameter in lambda (PR #89828)

2024-04-24 Thread John McCall via cfe-commits
@@ -4684,6 +4684,29 @@ LValue CodeGenFunction::EmitLValueForLambdaField(const FieldDecl *Field, else LambdaLV = MakeAddrLValue(AddrOfExplicitObject, D->getType().getNonReferenceType()); + +// Make sure we have an lvalue to the lamb

[clang] [clang codegen][NFC] Delete dead code in constant emission. (PR #90106)

2024-04-25 Thread John McCall via cfe-commits
https://github.com/rjmccall commented: The Apple fork does actually use this downstream (for address-sensitive `__ptrauth`), and we've recently (finally) been making progress in upstreaming that work. Obviously, we could delete it and then reinstate it when we catch up to this point in upstre

[clang] [clang] Fix `remove{CVR|Fast}Qualifiers` with 64-bit `Qualifiers::Mask` (PR #90329)

2024-04-28 Thread John McCall via cfe-commits
https://github.com/rjmccall approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/90329 ___ 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
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-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-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
@@ -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-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
@@ -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
@@ -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
@@ -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
@@ -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
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

<    3   4   5   6   7   8   9   10   11   >