Hi,
On 15/2/2022 下午 10:56, Segher Boessenkool wrote: > On Tue, Feb 15, 2022 at 11:01:03AM +0800, HAO CHEN GUI wrote: > Hi! > >> On 15/2/2022 上午 5:36, Segher Boessenkool wrote: >>> On Wed, Feb 09, 2022 at 10:43:17AM +0800, HAO CHEN GUI wrote: >>> All that are arguments for expanding to split form, not for removing >>> TImode from the iterator. And you leave PTImode, which *always* is in >>> GPRs! >> >From my understanding, PTImode has limitation that it needs to be assigned >> with an even/odd register pair. So it can't be split before the reload pass. > > TImode is put in an even/odd pair always as well. What is special about > PTImode here? TI is allowed in any GPRs. TI can be placed in r3/r4 or r4/r5 (both odd/even and even/odd) while PTI can only be placed in r4/r5 (even/odd). So if we split PTI before reload,the constraint is broken then PTI can be placed in any GPRs, I think. > >> Currently it is split after reload.> > > This prevents almost all optimisations. Splits after reload should be a > last resort thing. They almost always cause bigger problems than what > they are meant to solve. There aren't many splitters that *have* to run > after RA! > >>> (You'll also have to show it is *correct*, you need to prove (or show it >>> really likely :-) ) that after this change there are no TImode things >>> generated anywhere (anywhere!) that are no longer handled now). >>> >> Yes, the TI may be generated after expand pass and causes ICEs. So how about >> creating two mode iterators? One is for expand which doesn't include TImode, >> another is for the split which include TImode and make TImode to be split >> as early as possible? > > You can also have the expanders fail for TImode? That gives you a good > place to put in a code comment as well ;-) > Yes, I will take it. > > Segher
