Ahh I see, that makes a lot more sense. I’d want to change the TARGET_SCHED_ADJUST_PRIORITY hook?
Also, would it still make sense to change the costs of expensive loads even during instruction selection to give opportunities for optimizations like rematerialization? I’m thinking that it could be a lot more expensive to spill to DRAM than it is to just recompute a result, or spill to the scratchpad memory. Thanks, Sasha > On Apr 16, 2020, at 7:45 PM, Jim Wilson <j...@sifive.com> wrote: > > On Thu, Apr 16, 2020 at 7:28 PM Sasha Krassovsky <samo...@uw.edu> wrote: >> @Jim I saw you were from SiFive - I noticed that modifying the costs for >> integer multiplies in the riscv_tune_info structs didn’t affect the >> generated code. Could this be why? > > rtx_costs is used for instruction selection. For instance, choosing > whether to use a shift and add sequence as opposed to a multiply > depends on rtx_cost. rtx_cost is not used for instruction scheduling. > This uses the latency info from the pipeline model, e.g. generic.md. > It looks like I didn't read your first message closely enough and > should have mentioned this earlier. > > Changing multiply rtx_cost does affect code generation. Just try a > testcase multiplying by a number of small prime factors, and you will > see that which ones use shift/add and which ones use multiply depends > on the multiply cost in the riscv_tune_info structs. This also > factors into the optimization that turns divide by constant into a > multiply. When this happens depends on the relative values of the > multiply cost and the divide cost. > > Jim
