Hi! On Thu, May 20, 2021 at 04:29:07PM +0800, HAO CHEN GUI wrote: > On 19/5/2021 下午 9:20, Segher Boessenkool wrote: > >On Wed, May 19, 2021 at 04:36:00PM +0800, HAO CHEN GUI wrote: > >>-/* Define this macro if it is advisable to hold scalars in registers > >>- in a wider mode than that declared by the program. In such cases, > >>- the value is constrained to be within the bounds of the declared > >>- type, but kept valid in the wider mode. The signedness of the > >>- extension may differ from that of the type. */ > >>- > >>-#define PROMOTE_MODE(MODE,UNSIGNEDP,TYPE) \ > >>- if (GET_MODE_CLASS (MODE) == MODE_INT \ > >>- && GET_MODE_SIZE (MODE) < (TARGET_32BIT ? 4 : 8)) \ > >>- (MODE) = TARGET_32BIT ? SImode : DImode; > >>- > >And this part needs some more words in the commit message :-)
[ ... ] > >Also, how about something like > > > >#define PROMOTE_MODE(MODE,UNSIGNEDP,TYPE) \ > > if (GET_MODE_CLASS (MODE) == MODE_INT \ > > && GET_MODE_SIZE (MODE) < 4) \ > > (MODE) = SImode; > > > >(that is, promoting modes smaller than SImode to SImode). How does that > >compare? > > It hits an ICE when assigning a function return value to a variable. The > mode of variable is promoted to SImode, but the mode of return value is > promoted to DImode. Current GCC logical is either the mode of set_dest > is unchanged or the mode of set_dest matches the mode of function return > value. So that sounds like a bug in the generic code? > By the way, I tested the patch on ppc64 with m32 option. The SPECint > shows a little improvement(0.4%). So it's better not do any mode promotions. Interesting! Do you have an example that shows improved code for that, just like that "SI->DI promotion gets a superfluous extension" testcase you sent? Segher
