)]}'
{
  "commit": "11337e4250b9711176d1045a77186d717fae1aaa",
  "tree": "6f6d0fd84b6b4072b6a6d96983c1d494d62c1ac5",
  "parents": [
    "c7bec85f2b8e4daa28391c3805c87a3fc2ad1582"
  ],
  "author": {
    "name": "Eric Biggers",
    "email": "ebiggers@google.com",
    "time": "Wed Mar 19 07:37:50 2025 -0700"
  },
  "committer": {
    "name": "Boringssl LUCI CQ",
    "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Wed Mar 19 15:22:21 2025 -0700"
  },
  "message": "Clean up aes-gcm-avx512-x86_64.pl to assume 512-bit vectors\n\naes-gcm-avx512-x86_64.pl (originally aes-gcm-avx10-x86_64.pl) was\ndesigned to support multiple maximum vector lengths, while still\nutilizing AVX512 / AVX10 features such as the increased number of vector\nregisters.  However, the support for multiple maximum vector lengths\nturned out to not be useful.  Support for maximum vector lengths other\nthan 512 bits was just removed from the AVX10 specification, which\nleaves \"avoiding downclocking\" as the only remaining use case for\nlimiting AVX512 / AVX10 code to 256-bit vectors.  But the bad 512-bit\ndownclocking has gone away in new CPUs, and the separate VAES+AVX2 code\nwhich I ended up having to write anyway (for CPUs that support VAES but\nnot AVX512) provides nearly as good 256-bit support anyway.\n\nTherefore, clean up aes-gcm-avx512-x86_64.pl to not be written in terms\nof a generic vector length, but rather just assume 512-bit vectors.\n\nThis results in some minor changes to the generated assembly:\n\n- The labels in gcm_init_vpclmulqdq_avx512 and\n  gcm_ghash_vpclmulqdq_avx512 no longer have the suffixes that were used\n  to differentiate between VL\u003d32 and VL\u003d64.\n- gcm_init_vpclmulqdq_avx512 is now in a slightly different place in the\n  file, since (like the AVX2 equivalent) it\u0027s now generated at the\n  top level instead of via a Perl function that gets called later on.\n- The inc_2blocks label (only used for VL\u003d32) has been removed.\n- The code no longer goes out of its way to avoid using immediates of\n  4*VL, which is now always 256.  This was an optimization for VL\u003d32\n  which shortened some instructions by 3 bytes by keeping immediates in\n  the range [-128, 127].  With VL\u003d64 this optimization is not possible,\n  so we might as well just write the \"obvious\" code instead.\n\nChange-Id: I44027d4a81f7d9bdfd4c27e410de2d0158b10325\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/77848\nReviewed-by: David Benjamin \u003cdavidben@google.com\u003e\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "99c2c270cd32d284de2f2a997418deebc9e0c973",
      "old_mode": 33188,
      "old_path": "crypto/fipsmodule/aes/asm/aes-gcm-avx512-x86_64.pl",
      "new_id": "4b98b770ca02345f32bd7f4eb4a30b2914f6b309",
      "new_mode": 33188,
      "new_path": "crypto/fipsmodule/aes/asm/aes-gcm-avx512-x86_64.pl"
    },
    {
      "type": "modify",
      "old_id": "157feb578eadff4538dfaecdc9f34069d486736b",
      "old_mode": 33188,
      "old_path": "gen/bcm/aes-gcm-avx512-x86_64-apple.S",
      "new_id": "2ab2442be8680759a271f4f6f92534b37d20d08b",
      "new_mode": 33188,
      "new_path": "gen/bcm/aes-gcm-avx512-x86_64-apple.S"
    },
    {
      "type": "modify",
      "old_id": "56f1a4447b55874943f1a73e898bc2b6dbb435d4",
      "old_mode": 33188,
      "old_path": "gen/bcm/aes-gcm-avx512-x86_64-linux.S",
      "new_id": "4e7743182640ac0f4b658165cd50f9ce6b572f67",
      "new_mode": 33188,
      "new_path": "gen/bcm/aes-gcm-avx512-x86_64-linux.S"
    },
    {
      "type": "modify",
      "old_id": "6e06094068d2a0cad06228b9ebc140b66825d8f0",
      "old_mode": 33188,
      "old_path": "gen/bcm/aes-gcm-avx512-x86_64-win.asm",
      "new_id": "76811a0b97ac2748c6d2bb839de537dab214b2ce",
      "new_mode": 33188,
      "new_path": "gen/bcm/aes-gcm-avx512-x86_64-win.asm"
    }
  ]
}