This is the mail archive of the
mailing list for the GCC project.
Re: Indirect memory addresses vs. lra
> On Aug 8, 2019, at 1:21 PM, Segher Boessenkool <firstname.lastname@example.org> wrote:
> On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote:
>>> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov <email@example.com> wrote:
>>> The old reload (reload.c) supports such addressing. As modern mainstream architectures have no this kind of addressing, it was not implemented in LRA.
>> Is LRA only intended for "modern mainstream architectures"?
> I sure hope not! But it has only been *used* and *tested* much on such,
> so far. Things are designed to work well for modern archs.
>> If yes, why is the old reload being deprecated? You can't have it both ways. Unless you want to obsolete all "not modern mainstream architectures" in GCC, it doesn't make sense to get rid of core functionality used by those architectures.
>> Indirect addressing is a key feature in size-optimized code.
> That doesn't mean that LRA has to support it, btw, not necessarily; it
> may well be possible to do a good job of this in the later passes?
> Maybe postreload, maybe some peepholes, etc.?
Possibly. But as Vladimir points out, indirect addressing affects register allocation (reducing register pressure). In older architectures that implement indirect addressing, that is one of the key ways in which the feature reduces code size. While I can see how peephole optimization can convert a address load plus a register indirect into a memory indirect instruction, does that help the register become available for other uses or is post-LRA too late for that? My impression is that it is too late, since at this point we're dealing with hard registers and making one free via peephole helps no one else.