On Tue, Jun 07, 2022 at 04:17:04PM -0500, Peter Bergner wrote: > On 6/6/22 7:55 PM, Michael Meissner wrote: > > gcc/ > [snip] > > * config/rs6000/rs6000.opt (-mstore-vector-pair): New option. > [snip] > > diff --git a/gcc/config/rs6000/rs6000.opt b/gcc/config/rs6000/rs6000.opt > > index 4931d781c4e..79ceec6e6a5 100644 > > --- a/gcc/config/rs6000/rs6000.opt > > +++ b/gcc/config/rs6000/rs6000.opt > > @@ -624,6 +624,10 @@ mieee128-constant > > Target Var(TARGET_IEEE128_CONSTANT) Init(1) Save > > Generate (do not generate) code that uses the LXVKQ instruction. > > > > +; Generate (do not generate) code that uses the store vector pair > > instruction. > > +mstore-vector-pair > > +Target Undocumented Var(TARGET_STORE_VECTOR_PAIR) Init(0) Save > > + > > -param=rs6000-density-pct-threshold= > > Target Undocumented Joined UInteger Var(rs6000_density_pct_threshold) > > Init(85) IntegerRange(0, 100) Param > > When costing for loop vectorization, we probably need to penalize the loop > > body > > I think I mentioned this offline, but I'd prefer a negative target flag, > something like TARGET_NO_STORE_VECTOR_PAIR that defaults to off, meaning we'd > generate stxvp by default. Then I'd like to see MASK_NO_STORE_VECTOR_PAIR > added to power10's rs6000-cpu.def definition. That way, stxvp isn't generated > on Power10, but would be by default on any possible future cpus without > having to add a flag to those cpus rs6000-cpu.def entries.
I don't much care when the option is spelled, but I'm happy to go with whatever name people want. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meiss...@linux.ibm.com
