)]}'
{
  "log": [
    {
      "commit": "38a3f21959d5c68d3034d4d3cef0cc231ebce78a",
      "tree": "fae9ab2b683bd2494a1480c7453e1beeace0e836",
      "parents": [
        "df12b6fbd98883cc1714f731847b7628f2fb7f11"
      ],
      "author": {
        "name": "Aart Bik",
        "email": "ajcbik@google.com",
        "time": "Fri Oct 20 17:02:21 2017 -0700"
      },
      "committer": {
        "name": "Aart Bik",
        "email": "ajcbik@google.com",
        "time": "Fri Oct 27 10:50:36 2017 -0700"
      },
      "message": "Alignment optimizations in vectorizer.\n\nRationale:\nSince aligned data access is generally better (enables more efficient\naligned moves and prevents nasty cache line splits), computing and/or\nenforcing alignment has been added to the vectorizer:\n\n  (1) If the initial alignment is known completely and suffices,\n      then a static peeling factor enforces proper alignment.\n  (2) If (1) fails, but the base alignment allows, dynamically peeling\n      until total offset is aligned forces proper aligned access patterns.\n\nBy using ART conventions only, any forced alignment is preserved\nover suspends checks where data may move.\n\nNote 1:\nCurrent allocation convention is just 8 byte alignment on arrays/strings,\nso only ARM32 benefits. However, all optimizations are implemented in\na general way, so moving to a 16 byte alignment will immediately\ntake advantage of any new convention!!\n\nNote 2:\nThis CL also exposes how bad the choice of 12 byte offset of arrays\nreally is. Even though the new optimizations fix the misaligned, it\nrequires peeling for the most common case: 0 indexed loops. Therefore,\nwe may even consider moving to a 16 byte offset. Again the optimizations\nin this CL will immediately take advantage of that new convention!!\n\nTest: test-art-host test-art-target\n\nChange-Id: Ib6cc0fb68c9433d3771bee573603e64a3a9423ee\n"
    }
  ]
}