On Tue, Jul 02, 2019 at 07:36:21PM -0400, Michael Meissner wrote:
> On Mon, Jul 01, 2019 at 04:27:05PM -0500, Segher Boessenkool wrote:
> > 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.
>
> I'll look into it. Note, the length is used in two places. One at the end to
> generate the appropriate branches, but the other is in rs6000_insn_cost inside
> rs6000.c.
We'll need to update our insn_cost for prefixed, sure, it currently does
int n = get_attr_length (insn) / 4;
to figure out how many machine instructions a pattern is, and then uses
"n" differently for the different types of insn. We'll need to refine
this a bit for prefixed instructions.
> This occurs before the final passes, so it is important that even
> though the insn will be split, that the length is still set. However, things
> are rather inconsistant, in that sometimes the length field is accurate, and
> sometimes not.
It *has* to be correct; it is allowed to be pessimistic though. This
is used to determine if a B-form branch can reach, for example. You get
ICEs if it isn't correct. Only on very few testcases, of course :-(
> I'm finding that the rs6000_insn_cost issue really muddies things up,
> particularly if a vector load/store insn is done in gpr registers, where it
> can
> be 4 insns.
Yeah, it doesn't handle vectors specially *at all* currently, not even
for FP in vectors. It is pretty much just a switch over the "type", and
for everything vector it gets to
default:
cost = COSTS_N_INSNS (n);
(with the above "n") which is a pretty coarse approximation to the truth ;-)
You could try #undef'ing TARGET_INSN_COST (in rs6000.c) for now, and hope
that rs6000_rtx_costs does better for what you need right now. In the end
it will have to be fixed properly, insn_cost is quite important.
Segher
