@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -1121,3 +1121,99 @@ bool SemaHLSL::CheckBuiltinFunctionCall(unsigned
BuiltinID, CallExpr *TheCall) {
}
return false;
}
+
+bool SemaHLSL::CheckCompatibleParameterABI(FunctionDecl *New,
+ FunctionDecl *Old) {
+ if (New->getNumPar
@@ -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
@@ -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
@@ -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)) {
@@ -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
@@ -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
@@ -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());
+
@@ -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
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
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
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
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
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
@@ -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
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
@@ -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
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
@@ -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);
@@ -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
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
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
@@ -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);
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
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
@@ -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
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
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
@@ -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
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
@@ -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
@@ -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
@@ -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
@@ -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
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
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
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
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
@@ -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
@@ -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
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
@@ -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
@@ -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
@@ -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);
+
@@ -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
@@ -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 !=
@@ -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
@@ -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
@@ -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 !=
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
@@ -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()`."));
+//======//
+//
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
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
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
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
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
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
_
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
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
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
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
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-
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
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
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
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
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
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
__
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
@@ -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
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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
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
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
@@ -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
@@ -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
@@ -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
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
@@ -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
@@ -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
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
@@ -5432,6 +5434,57 @@ LValue CodeGenFunction::EmitOpaqueValueLValue(const
OpaqueValueExpr *e) {
return getOrCreateOpaqueLValueMapping(e);
}
+LValue CodeGenFunction::BindHLSLOutArgExpr(const HLSLOutArgExpr *E,
+ Address OutTemp) {
+
@@ -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
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
@@ -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
@@ -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;
@@ -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
@@ -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
@@ -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
@@ -5432,6 +5434,57 @@ LValue CodeGenFunction::EmitOpaqueValueLValue(const
OpaqueValueExpr *e) {
return getOrCreateOpaqueLValueMapping(e);
}
+LValue CodeGenFunction::BindHLSLOutArgExpr(const HLSLOutArgExpr *E,
+ Address OutTemp) {
+
@@ -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
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
701 - 800 of 1051 matches
Mail list logo