Looks good.

Add the missing attributes #0 = { strictfp }

In D68117#1707578, @SouraVX wrote:

In D68117#1702595, @probinson wrote:

We really do want to pack the four mutually exclusive cases into two bits. I have tried to give more explicit comments inline to explain how you would do this. It really should work fine, recognizing that the "not defaulted" case is not explicitly represented in the textual IR because it uses a zero value in the defaulted/deleted subfield of SPFlags.

Thanks Paul, for suggesting this. Your approach works fine. But as I was working on some lvm-dwarfdump test cases. We seems to miss one corner case --
Consider this test case;
class foo{

foo() = default;
~foo() = default;
 void not_special() {}

};
void not_a_member_of_foo(){}

Now I'm getting DW_AT_defaulted getting emitted with value DW_DEFAULTED_no, for functions "not_special" and "not_a_member_of_foo". This behavior is undesirable since, DW_AT_defaulted attributes is only valid for C++ special member functions{Constructors/Destructors, ...}.

Please correct me if I'm wrong -- Now This attributes to- implicitly defined "0" NotDefaulted bit. which is getting checked{that's fine as long as we have a dedicated bits for distinguishing} and true for every subprogram or function in a CU.
void DwarfUnit::applySubprogramAttributes( ...
...
else if (SP->isNotDefaulted())

addUInt(SPDie, dwarf::DW_AT_defaulted, dwarf::DW_FORM_data1,
        dwarf::DW_DEFAULTED_no);

...

• ...and fix namespace...

@edward-jones: what LLVM cmake options are you using to test this?

In CoreMark-Pro, when the execution model is 1 instr == 1 cycle, with this patch the results I get is that sha-test improves by +1.43% in RV64 (GC, LP64D). For all other sub-benchmarks the performance differences round to 0.00%. There's no change to sha-test in RV32 before and after the patch.

• Fix Expected<> types

• Apply review feedback (-auto, -memset, +comments)

This is indeed an issue that would be nice to fix, I've often been annoyed by clang just defaulting to the root when some misconfiguration occurs. I have to wonder though, this patch only changes the clang RISC-V toolchain driver, but the problem isn't specific to RISC-V. Couldn't this tweak be generalized and made to apply to multiple/all target drivers?

Rebase and address iteration issue (hat tip to both commenters!).