[NFC] Fix uninitialized member variable use in RVVEmitter::createRVVIntrinsics()

[schittir]

Summary

Found by Coverity static analysis tool.

[jrtc27]

None of the other fields are initialised, so blindly initialising it alone to 0 here seems highly suspect. What's the actual case in which it's used whilst uninitialised?

[jrtc27]

The field should just be deleted. D126742 added it without any uses, and I don't know what the original intent was. Maybe it was used before the bitfields were added and it stuck around rather than being GC'ed. I don't know why Coverity would care about this though when it's never read from, there's nothing wrong with that, unless the warning is in fact that the field is entirely unreferenced?

[schittir]

In D146847#4220697, @jrtc27 wrote:

None of the other fields are initialised, so blindly initialising it alone to 0 here seems highly suspect. What's the actual case in which it's used whilst uninitialised?

Coverity complains about SR.PolicyBitMask being uninitialized when calling SemaRecords->push_back(SR)

[schittir]

In D146847#4220717, @jrtc27 wrote:

The field should just be deleted. D126742 added it without any uses, and I don't know what the original intent was. Maybe it was used before the bitfields were added and it stuck around rather than being GC'ed. I don't know why Coverity would care about this though when it's never read from, there's nothing wrong with that, unless the warning is in fact that the field is entirely unreferenced?

Yea, that would make sense. I am up for deleting the field. Coverity does indeed complaining about uninitialized use of the SR.PolicyBitMask when calling push_back - surprisingly nothing about the field being unreferenced.

[jrtc27]

In D146847#4220721, @schittir wrote:

In D146847#4220697, @jrtc27 wrote:

None of the other fields are initialised, so blindly initialising it alone to 0 here seems highly suspect. What's the actual case in which it's used whilst uninitialised?

Coverity complains about SR.PolicyBitMask being uninitialized when calling SemaRecords->push_back(SR)

Isn't that precisely the case https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_222.htm makes legal? (Which I assume/hope applies equally to C++...)

[schittir]

Deleting the member PolicyBitMask

[aaron.ballman]

LGTM, but you should fix up the commit message when you land since the patch has changed away from what's described in the summary.

clang/utils/TableGen/RISCVVEmitter.cpp

for (auto RequiredFeature : RequiredFeatures) {
       RVVRequire RequireExt = StringSwitch<RVVRequire>(RequiredFeature)
                                   .Case("RV64", RVV_REQ_RV64)
                                   .Case("FullMultiply", RVV_REQ_FullMultiply)
                                   .Default(RVV_REQ_None);
       assert(RequireExt != RVV_REQ_None && "Unrecognized required feature?");
       SR.RequiredExtensions |= RequireExt;
     }
 
+    SR.PolicyBitMask = 0;
     SR.NF = NF;
     SR.HasMasked = HasMasked;
     SR.HasVL = HasVL;
     SR.HasMaskedOffOperand = HasMaskedOffOperand;
     SR.HasTailPolicy = HasTailPolicy;
     SR.HasMaskPolicy = HasMaskPolicy;
     SR.UnMaskedPolicyScheme = static_cast<uint8_t>(UnMaskedPolicyScheme);
     SR.MaskedPolicyScheme = static_cast<uint8_t>(MaskedPolicyScheme);