Maxim Kuvyrkov ma...@codesourcery.com writes:
I thought I'll butt in since I did a very similar thing for
sync_memmodel a couple of months ago.
Thanks.
+ /* We take care in instruction definitions to make sure accum_in operand is
+ a register_operand or [a more restrictive]
On 14/08/2012, at 7:08 PM, Richard Sandiford wrote:
OK with those changes, thanks.
Checked in with the noted changes and a fixed bug.
It turns out that mips_linked_madd_p is also called via
mips_macc_chains_reorder, which may pass a (use ...) instruction, which causes
get_attr_* to blow up.
On 9/08/2012, at 7:10 AM, Richard Sandiford wrote:
Hmm, yeah, it does look like they should be using mips_linked_madd_p
instead, except that mips_linked_madd_p isn't yet wired up to handle
DSP macs. Rather than pattern-match them all, the easiest thing would
probably be to define a new
Sandra Loosemore san...@codesourcery.com writes:
+;; Before reload, all multiplier is registered as imul3 (which has a long
+;; latency). We temporary jig the latency such that the macc groups
+;; are scheduled closely together during the first scheduler pass.
+(define_bypass 1
Sandra Loosemore san...@codesourcery.com writes:
The existing scheduler bypass information for madd on the 74k uses some
bits copied from the 24k, and is not quite correct. This patch is based
on one originally sent to us by MIPS and has been present in our local
source base for years.
On 08/04/2012 07:48 AM, Richard Sandiford wrote:
Sandra Loosemoresan...@codesourcery.com writes:
The existing scheduler bypass information for madd on the 74k uses some
bits copied from the 24k, and is not quite correct. This patch is based
on one originally sent to us by MIPS and has been
