bob80905 wrote:
Looked over the DXC codebase and didn't find any hits on deadonreturn, so yeah
I think such a test wouldn't make sense.
But, then, wouldn't this be a better approach?
```
// Depending on the ABI, this may be either a byval or a dead_on_return
// argument.
if (AI.getIndirectByVal()) {
if (auto ParamABI = FI.getExtParameterInfo(ArgNo).getABI();
ParamABI != ParameterABI::HLSLOut &&
ParamABI != ParameterABI::HLSLInOut) {
Attrs.addByValAttr(getTypes().ConvertTypeForMem(ParamType));
}
} else {
// Add dead_on_return when the object's lifetime ends in the callee.
// This includes trivially-destructible objects, as well as objects
// whose destruction / clean-up is carried out within the callee
// (e.g., Obj-C ARC-managed structs, MSVC callee-destroyed objects).
if (!ParamType.isDestructedType() || !ParamType->isRecordType() ||
ParamType->castAs<RecordType>()
->getDecl()
->isParamDestroyedInCallee())
Attrs.addAttribute(llvm::Attribute::DeadOnReturn);
}
```
If DeadOnReturn is not relevant in HLSL, then this change would be affecting
other compilation behavior outside of HLSL, right?
https://github.com/llvm/llvm-project/pull/150495
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
