On Mon, 14 Oct 2019 15:18:08 -0600 Jeff Law <l...@redhat.com> wrote: > On 10/8/19 4:34 AM, Jozef Lawrynowicz wrote: > > In the large memory model, MSP430 instructions have some useful properties > > when > > performing byte, word or address-word writes to registers or memory: > > - Byte-writes to registers clear bits 19:8 > > - Word-writes to registers clear bits 19:16 > > - PSImode writes to memory clear bits 16:4 of the second memory word > > > > This patch makes use of these properties to optimize some zero_extend > > instructions. > > > > There are some "synonyms" for these zero_extend instructions that combine > > searches for when optimizing code which manipulates PSImode pointers. The > > patch > > adds a number of these unnamed RTL insns. > > > > The first patch is an "obvious" patch with no functional changes, which just > > reorders the zero_extend insns in the md file so we get them in one place. > > The second patch has functional changes. > > > > (Note that the patches will not apply cleanly unless the recently submitted > > patch to implement post increment addressing has been applied: > > https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00492.html) > > > > Successfully regtested on trunk in the small and large memory models. > > > > Ok for trunk? > > > > Jozef Lawrynowicz (2): > > MSP430: Reorder and group zero_extend insns in msp430.md > > MSP430: PSImode pointer manipulation and zero extend insn > > optimizations > FWIW, we often end up describing some of this stuff via > WORD_REGISTER_OPERATIONS. However that may not work for word sizes that > are not a power of two bits. > > I only mention it because it may be worth a bit of experimentation on > your end.
We have WORD_REGISTER_OPERATIONS defined to 1, but UNITS_PER_WORD is always 2 bytes. But yes I should look at how the RTL passes use this macro. I played around with some other macros e.g. TARGET_TRULY_NOOP_TRUNCATION, REGMODE_NATURAL_SIZE but none had any desirable effect. It feels like there is still something that needs to be fixed which will unlock better RTL generation for PSImode operations, but I believe I've exhausted the target macros which can influence this. So maybe something in the middle-end needs to be added or extended. I should also study some of the other ports with PSImode registers more closely. P.S. I took at the old mn10200 port as you suggested before but I wasn't able to improve code gen by changing any of the target macros that were defined differently. The combiner patterns for pointer manipulation in the port were similar but not close enough to the patterns I added in this patch. Thanks, Jozef > > jeff
