Segher, Thanks for your comments. Here are my comments and questions.Thanks.
On 15/2/2022 上午 5:36, Segher Boessenkool wrote: > Hi! > > On Wed, Feb 09, 2022 at 10:43:17AM +0800, HAO CHEN GUI wrote: >> This patch removes TImode from mode iterator BOOL_128. Thus, bool >> operations (AND, IOR, XOR, NOT) >> on TImode will be split to the relevant operations on word mode during >> expand (in optabs.c). > > But we also want to allow TImode in VSRs. This of course is a never- > ending story, no choice works very well here. > >> Potential >> optimizations can be implemented after the split. The former practice splits >> it after the reload >> pass which is too later for some optimizations. The new test case >> illustrates it. > > 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. Currently it is split after reload.> > It may be that only leaving the "V" modes there works well; that needs > testing though, more than just asaserting this. > > Just doing it and handling the ICEs later is fine, but in stage 1. > > (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? > > Segher
