Only cosmetic comments.

Thanks for the patch. Apparently both gcc and clang are fine if the attribute is placed before the definition: https://godbolt.org/z/5aTrcb, so we could do without the ifdefs.
(Though gcc does not know about the attribute, but that's also the case with the current version)

Improve commit message.

Thanks for the comments.

...and add a side-effecting instruction at the top.

Make the test more robust to future optimizations as suggested by James.

Simplify the test as suggested by James.

Update comment.

Thanks for the repro. I think a better fix is D92375 (missing split).

Thanks, comments addressed.

Add to release notes.

Thanks, could you please add a unit test for this ?

LGTM for llvm-exegesis

This was eventually landed as rG8383fddc4fa9b4e61954e5ac93b00719a39d2291

In D90742#2389801, @anna wrote:

hi @courbet,
our internal buildbots at Azul has failed because of an older assembler. We’ve taken in all commits/reverts/relands w.r.t this change upto Nov 4th.

The specific failure is:
/tmp/cc2lBtEi.s: Assembler messages:
/tmp/cc2lBtEi.s:541: Error: no such instruction: `fxsave64 16(%rax)'
/tmp/cc2lBtEi.s:566: Error: no such instruction: `fxrstor64 16(%rdi)'
/tmp/cc2lBtEi.s:592: Error: no such instruction: `fxrstor64 16(%rdi)'
make[2]: *** [tools/llvm-exegesis/lib/X86/CMakeFiles/LLVMExegesisX86.dir/Target.cpp.o] Error 1

Any suggestions to fix this apart from an upgrade (which seems to be a very invasive change on our machines)?

In D90742#2373442, @courbet wrote:

In D90742#2373438, @thakis wrote:

Looks like this doesn't build on windows: http://45.33.8.238/win/27220/step_4.txt

Thanks, I missed this bot. I'll send a fix.

In D90742#2373438, @thakis wrote:

Looks like this doesn't build on windows: http://45.33.8.238/win/27220/step_4.txt

Address review comments

Thanks, PTAL.

This looks good for the llvm-exegesis part. I'm not familiar enough with the PowerPC target to review the rest.

If you're not using llvm-exegesis you can disable this with the LLVM_ENABLE_LIBPFM cmake option.
But I'll revert this until @oontvoo can fix llvm/cmake/modules/FindLibpfm.cmake

I have no idea what the policy is WRT size for compiler-rt. How big is the diff if you take code size into consideration ?

Sorry for taking that long, this is a dense review. Overall this looks good, and the renaming and splitting actually also improve the readability of the non-x86 part.
I only have style comments.

Only style comments left

In D83192#2135079, @gchatelet wrote:

In D83192#2135019, @courbet wrote:

Can you add a unit test for this ?

I'll add the following test as a separate commit if it LGTY.
Note: I can't use EXPECT_EQ because it takes the arguments by const & and the properties are static constexpr, the compiler complains about undefined reference.

TEST(BitfieldsTest, Properties) {
  using A = Bitfield::Element<bool, 0, 1>;
  EXPECT_TRUE(A::FirstBit == 0U);
  EXPECT_TRUE(A::LastBit == 0U);
  EXPECT_TRUE(A::Shift == 0U);
  EXPECT_TRUE(A::Bits == 1U);

  using B = Bitfield::Element<unsigned, 3, 4>;
  EXPECT_TRUE(B::FirstBit == 3U);
  EXPECT_TRUE(B::LastBit == 6U);
  EXPECT_TRUE(B::Shift == 3U);
  EXPECT_TRUE(B::Bits == 4U);
}

Can you add a unit test for this ?

Cool ! Only minor comments.