On Wed, Jul 03, 2019 at 01:06:27PM -0400, Michael Meissner wrote: > On Mon, Jul 01, 2019 at 04:27:05PM -0500, Segher Boessenkool wrote: > > > @@ -7385,8 +7385,8 @@ (define_insn "*mov<mode>_softfloat" > > > *, *, *, *") > > > > > > (set_attr "length" > > > - "4, 4, 4, 4, 4, 4, > > > - 4, 4, 8, 4")]) > > > + "*, *, *, *, *, *, > > > + *, *, 8, *")]) > > > > [ That last line should start with a tab as well. ] > > Ok. > > > The entry before the 8 is split as well. Maybe that should be "4", to > > stand out? I don't know what works better; your choice. > > Though the "G" constraint specifically says for SFmode it is a single > instruction.
Sure. But that doesn't mean much, does it? You cannot see the actual split insns here, and that the constraint is for "Constant that can be copied into GPR with two insns for DF/DD and one for SF/SD." is pretty weak :-) The default is one insn, that's what * does. You can still use 4 though when that is beneficial, to make things a tiny bit clearer maybe. > > > @@ -7696,8 +7696,8 @@ (define_insn "*mov<mode>_softfloat64" > > > *, *, *") > > > > > > (set_attr "length" > > > - "4, 4, 4, 4, 4, 8, > > > - 12, 16, 4")]) > > > + "*, *, *, *, *, 8, > > > + 12, 16, *")]) > > > > Same for the last entry here. > > Well technically that alternative will never fire (destination is "*h" and > source is "0"), and a nop is emitted. If it can never fire we should remove it. But it *can* fire, or I cannot prove it cannot anyway. Can you? This would be a lovely cleanup if we could make it :-/ > I do wish we could never ever load > floating point into SPR registers. I've tried in the reload days to eliminate > it, but there was always some abort if it got eliminated. It should never load anything into CTR, LR, or VRSAVE, period. :-) Maybe we should use those as fixed registers, not allocatable as they are now. Segher
