This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Prepare for prefixed instructions on PowerPC
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Michael Meissner <meissner at linux dot ibm dot com>, gcc-patches at gcc dot gnu dot org, dje dot gcc at gmail dot com
- Date: Tue, 2 Jul 2019 19:09:20 -0500
- Subject: Re: [PATCH] Prepare for prefixed instructions on PowerPC
- References: <20190627201800.GA30249@ibm-toto.the-meissners.org> <20190701212704.GF18316@gate.crashing.org> <20190702233621.GA18456@ibm-toto.the-meissners.org>
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
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
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.