On Tue, Aug 31, 2021 at 05:52:48PM -0500, Segher Boessenkool wrote: > Hi! > > On Thu, Aug 26, 2021 at 05:28:42PM -0400, Michael Meissner wrote: > > On Thu, Aug 26, 2021 at 02:17:57PM -0500, will schmidt wrote: > > > On Wed, 2021-08-25 at 15:46 -0400, Michael Meissner wrote: > > > > Generate XXSPLTIDP on power10. > > > > > > > > I have added a temporary switch (-mxxspltidp) to control whether or not > > > > the > > > > XXSPLTIDP instruction is generated. > > > > > > How temporary? > > > > Until we decide we no longer need to disable the option to do tests. > > Probably > > at the end of stage1. > > Don't do it at all please. If it is useful to disable some new strategy > for generating constants, a (temporary or at least undocumented) flag > for that can be handy. But a flag to disable separate insns is a > liability, it makes the compiler much more fragile, makes changing the > compiler hard because of all the surprises hidden. > > > > > (xxspltidp_operand): New predicate. > > > > > > Will there ever be another instruction using the SF/DF CONST_DOUBLE or > > > V2DF CONST_VECTOR ? I tentatively question the name of the operand, > > > but defer.. > > > > This is the convention I've used for adding other instructions like > > xxspltib. > > The only reason it is a good idea here is because of the strange > behaviour this insn has with single precision subnormals. In general > a better name here would be something like "sf_as_int_operand". The > insn should probably not allow anything else than bit patterns, not > floating point constants, have a separate pattern for that (that can > then forward to the integer one). > > > This way we have just one place that centralizes the knowledge about the > > instruction. > > That one place should be the define_insn for it.
But you need the predicate and constraint for this to work. That is what I was talking about. The define_insn is simple with this current method. Otherwise, the define_insn has to reparse the RTL. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
