Thanks for your replies! I looked into the address spaces, and I think it’s easier to inform the RTX costs just using the attribute, but it was a good suggestion. Also, rtx_costs in rtlanal.c indeed seems to be the source of the problem. The SET expression does not look at the costs of its operands. I’ve also noticed a few other issues that could lead to poor code generation, such as multiplications and divisions having hardcoded costs instead of using the target-specific costs. Is my assessment correct that this could be causing issues?
@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? Thanks again! Sasha Krassovsky > On Apr 13, 2020, at 12:08 PM, Jim Wilson <j...@sifive.com> wrote: > > On Sat, Apr 11, 2020 at 4:28 PM Sasha Krassovsky via Gcc > <gcc@gcc.gnu.org> wrote: >> I’m currently modifying the RISC-V backend for a manycore processor where >> each core is connected over a network. Each core has a local scratchpad >> memory, but can also read and write other cores’ scratchpads. I’d like to >> add an attribute to give a hint to the optimizer about which loads will be >> remote and therefore longer latency than others. > > GCC has support for the proposed named address space extension to the > ISO C standard. You may be able to use this instead of defining your > own attributes. I don't know if this helps with the rtx cost > calculation though. This is mostly about support for more than one > address space. See "Named Address Spaces" in the gcc internals docs, > and the *_ADDR_SPACE_* stuff in the sources. > > The problem may be one similar to what Alan Modra mentioned. I would > suggest stepping through the cost calculation code in a debugger to > see what is happening. > > Jim
