This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Forward propagation before register allocation

I have been working on AVR port and have come across many instances where poor code is produced due to the absence of effective forward propagation of operands before register allocation.

The AVR target in particular benefits from register lowering pass as many physical registers and instructions are only 8 bits. However, most of the opportunities this creates for register and instruction elimination are not realized as the only following pass that can help is register allocation which has minimal propagation capabilities - and no instruction simplifications.

Similarly, instruction splitting created at the combine stage and before reload do not reliase the expected benefits from spliiting into 8 bit operations. In fact if any new pseudo are created by a split this often turn into new hard register.

Targets other than the AVR which have small sized registers (i86 and 68HC11 for example) are likely to have the same issues.

There have been suggestions in tha pass to split all instructions by RTL expanders. Indeed I and others have explored this. However, this has proved fruitless as this also requires a change to a non-CC0 target. At this time this cannot be realized due to problems reloading addresses and reloading arithmetic carry operations.

Hybrid approaches that split some instructions using RTL expanders have also been tried. But the resultant complexity (some split -some are not) then defeats early RTL optimizations -so we loose more than we gain.

With an additional forward propagation pass prior to register allocation the full benefits of Subreg lowering and splitting are obtained.

I realise than nobody is keen on new passes. Yet I can see no other way in which this problem can be addressed.

From a target viewpoint, moving fwprop2 latter would be fine. Adding a target dependent pass (before reload) would be also be fine. Indeed any way we could get better forward propagation/simplification after combine/lowering and before register allocation would be great.

Can I humbly ask that the maintainers of gcc seriously consider this request and provide some means by which to solve the issue.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]