)]}'
{
  "commit": "097d4a9311cfc4c41cd885ee63285ef072a0e8fa",
  "tree": "e9b95cedfeb6ba6b2baf3d242942a1399de68608",
  "parents": [
    "d782390469b7555f6cf4d8ff29777c941717c5d2"
  ],
  "author": {
    "name": "Shreya Munnangi",
    "email": "smunnang@qti.qualcomm.com",
    "time": "Tue Aug 04 07:16:37 2026 -0600"
  },
  "committer": {
    "name": "Jeff Law",
    "email": "jeffrey.law@oss.qualcomm.com",
    "time": "Tue Aug 04 07:20:01 2026 -0600"
  },
  "message": "[RISC-V][PR target/108031] Expose address computations for atomic memory operations\n\nThis is a patch from Shreya that takes a step towards fixing pr108031.\n\nAccess to objects in static storage requires a high/lo_sum pair on RISC-V.\nOften, but not always, the lo_sum expression can be folded into the actual\nmemory reference.  One of the common cases where it can *not* fold in is atomic\nmemory operations.  So if (for example) we access nearby fields in a structure\nin static memory we\u0027ll often see\n\n\tlui     a5,%hi(s)\n\tli      a4,1\n\taddi    a5,a5,%lo(s)\n\tamoadd.w a0,a4,0(a5)\n\tlui     a5,%hi(s+4) \u003c-- this should be: addi a5, a5, 4\n\taddi    a5,a5,%lo(s+4) \u003c-- this should be removed\n\tamoadd.w a3,a4,0(a5)\n\tadd     a0,a0,a3\n\nWe\u0027d like to replace the second lui+addi pair with a single addi.  That\u0027s\nnormally a job for CSE, but due to implementation details of the RISC-V atomics\nwe\u0027re failing to even expose those addresses to CSE.\n\nThe core issue is the predicates on these instructions are wider than the\nconstraints and as a result the lo_sum stays folded into the memory reference\nuntil LRA realizes the constraints don\u0027t match and the lo_sum part of the\naddress computation gets reloaded.\n\nThe fix is straightforward.  Tighten the operand predicates.  RISC-V only\nallows simple memory indirect operands for these instructions, yet surprisingly\nwe didn\u0027t have a predicate for that kind of address.  This patch adds an\nappropriate predicate, then uses it on the dozen or so relevant\npatterns/expanders.\n\nThat\u0027s enough to expose the address calculation to CSE, schedulers, etc.  In my\n(Jeff\u0027s) opinion the patch stands as an independent improvement, even though it\ndoesn\u0027t fix 108031.  The next (and final) step to fix 108031 will most likely\nbe a costing model fix.  ie, CSE will do the right thing with the addresses are\nfully exposed, but it rejects the changes because the RISC-V cost model is\nbroken.\n\nThis has been bootstrapped and regression tested on the c920.  K3 bootstrap \u0026\nregression test was just about done when a cat went crazy behind my desk and\nultimately dislodged the power cable from the wall.   It\u0027s restarted, but\nresults are now 9 hours out :(  riscv32-elf and riscv64-elf both worked fine,\nof course.\n\nI\u0027m pushing this to the trunk of Shreya\u0027s behalf.\n\n\tPR target/108031\ngcc\n\t* config/riscv/predicates.md (riscv_atomic_memory_operand): New\n\tpredicate.\n\t* config/riscv/sync.md (\u003catomic_optab\u003e\u003cmode\u003e pattern and expander):\n\tUse riscv_atomic_memory_operand.\n\t(amo_atomic_\u003catomic_optab\u003e\u003cmode\u003e): Likewise.\n\t(lrsc_atomic_\u003catomic_optab\u003e\u003cmode\u003e): Likewise.\n\t(atomic_fetch_\u003catomic_optab\u003e\u003cmode): Likewise.\n\t(amo_atomic_fetch_\u003catomic_optab\u003e\u003cmode\u003e): Likewise.\n\t(lrsc_atomic_fetch_\u003catomic_optab\u003e\u003cmode\u003e): Likewise.\n\t(subword_atomic_fetch_strong_\u003catomic_optab\u003e): Likewise.\n\t(atomic_fetch_nand\u003cmode\u003e): Likewise.\n\t(subword_atomic_fetch_strong_nand): Likewise.\n\t(zabha_atomic_fetch_\u003catomic_optab\u003e\u003cmode\u003e): Likewise.\n\t(lrsc_atomic_fetch_\u003catomic_optab\u003e\u003cmode\u003e): Likewise.\n\t(atomic_exchange\u003cmode\u003e): Likewise.\n\t(amo_atomic_exchange\u003cmode\u003e): Likewise.\n\t(amo_atomic_exchange\u003cmode\u003e_extended): Likewise.\n\t(lrsc_atomic_exchange\u003cmode\u003e): Likewise.\n\t(subword_atomic_exchange_strong): Likewise.\n\t(zacas_atomic_cas_value_strong\u003cmode\u003e): Likewise.\n\t(zalrsc_atomic_cas_value_strong\u003cmode\u003e): Likewise.\n\t(subword_atomic_cas_strong): Likewise.\n\t(atomic_test_and_set): Likewise.\n\ngcc/testsuite\n\t* gcc.target/riscv/pr108031.c: New test.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "df1a76049f40d5fe02acf62ac14f4afc5dbb5339",
      "old_mode": 33188,
      "old_path": "gcc/config/riscv/predicates.md",
      "new_id": "3ee9042b949c3557ecf2f921105bce30a98753b6",
      "new_mode": 33188,
      "new_path": "gcc/config/riscv/predicates.md"
    },
    {
      "type": "modify",
      "old_id": "a046519c8351501e7e6157a2e3c6792131baa705",
      "old_mode": 33188,
      "old_path": "gcc/config/riscv/sync.md",
      "new_id": "0d983ce6024573427319841e19bd35ef0f71392c",
      "new_mode": 33188,
      "new_path": "gcc/config/riscv/sync.md"
    },
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "6f7e13a4b2b6b8e398dec8c9d68386ac164b796b",
      "new_mode": 33188,
      "new_path": "gcc/testsuite/gcc.target/riscv/pr108031.c"
    }
  ]
}