On Tue, 1 Nov 2022, Jiufu Guo wrote: > Segher Boessenkool writes: > > > On Mon, Oct 31, 2022 at 04:13:38PM -0600, Jeff Law wrote: > >> On 10/30/22 20:42, Jiufu Guo via Gcc-patches wrote: > >> >We know that for struct variable assignment, memory copy may be used. > >> >And for memcpy, we may load and store more bytes as possible at one time. > >> >While it may be not best here: > > > >> So the first question in my mind is can we do better at the gimple > >> phase?  For the second case in particular can't we just "return a" > >> rather than copying a into then returning ?  This feels > >> a lot like the return value optimization from C++.  I'm not sure if it > >> applies to the first case or not, it's been a long time since I looked > >> at NRV optimizations, but it might be worth poking around in there a bit > >> (tree-nrv.cc). > > > > If it is a bigger struct you end up with quite a lot of stuff in > > registers. GCC will eventually put that all in memory so it will work > > out fine in the end, but you are likely to get inefficient code. > Yes. We may need to use memory to save regiters for big struct. > Small struct may be practical to use registers. We may leverage the > idea that: some type of small struct are passing to function through > registers. > > > > > OTOH, 8 bytes isn't as big as we would want these days, is it? So it > > would be useful to put smaller temportaries, say 32 bytes and smaller, > > in registers instead of in memory. > I think you mean: we should try to registers to avoid memory accesing, > and using registers would be ok for more bytes memcpy(32bytes). > Great sugguestion, thanks a lot! > > Like below idea: > [r100:TI, r101:TI] = src; //Or r100:OI/OO = src; > dest = [r100:TI, r101:TI]; > > Currently, for 8bytes structure, we are using TImode for it. > And subreg/fwprop/cse passes are able to optimize it as expected. > Two concerns here: larger int modes(OI/OO/..) may be not introduced yet; > I'm not sure if current infrastructure supports to use two more > registers for one structure. > > > > >> But even so, these kinds of things are still bound to happen, so it's > >> probably worth thinking about if we can do better in RTL as well. > > > > Always. It is a mistake to think that having better high-level > > optimisations means that you don't need good low-level optimisations > > anymore: in fact deficiencies there become more glaringly apparent if > > the early pipeline opts become better :-) > Understant, thanks :) > > > > >> The first thing that comes to my mind is to annotate memcpy calls that > >> are structure assignments.  The idea here is that we may want to expand > >> a memcpy differently in those cases.   Changing how we expand an opaque > >> memcpy call is unlikely to be beneficial in most cases.  But changing > >> how we expand a structure copy may be beneficial by exposing the > >> underlying field values.   This would roughly correspond to your method > >> #1. > >> > >> Or instead of changing how we expand, teach the optimizers about these > >> annotated memcpy calls -- they're just a a copy of each field.   That's > >> how CSE and the propagators could treat them. After some point we'd > >> lower them in the usual ways, but at least early in the RTL pipeline we > >> could keep them as annotated memcpy calls.  This roughly corresponds to > >> your second suggestion. > > > > Ideally this won't ever make it as far as RTL, if the structures do not > > need to go via memory. All high-level optimissations should have been > > done earlier, and hopefully it was not expand tiself that forced stuff > > into memory! :-/ > Currently, after early gimple optimization, the struct member accessing > may still need to be in memory (if the mode of the struct is BLK). > For example: > > _Bool foo (const A a) { return a.a[0] > 1.0; } > > The optimized gimple would be: > _1 = a.a[0]; > _3 = _1 > 1.0e+0; > return _3; > > During expand to RTL, parm 'a' is store to memory from arg regs firstly, > and "a.a[0]" is also reading from memory. It may be better to use > "f1" for "a.a[0]" here. > > Maybe, method3 is similar with your idea: using "parallel:BLK {DF;DF;DF; DF}" > for the struct (BLK may be changed), and using 4 DF registers to access > the structure in expand pass. I think for cases like this it might be a good idea to perform SRA-like analysis at RTL expansion time when we know how parameters arrive (in pieces) and take that knowledge into account when assigning the RTL to a decl. The same applies for the return ABI. Since we rely on RTL to elide copies to/from return/argument registers/slots we have to assign "layout compatible" registers to the corresponding auto vars. > > Thanks again for your kindly and helpful comments! > > BR, > Jeff(Jiufu) > > > > > > > Segher > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)