Re: prevent GCC from re-arranging two emit_insn()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 11, 2019 at 10:57:17PM -0600, Jeff Law wrote:
> On 4/11/19 2:43 PM, William Tambe wrote:
> > Wouldn't the blockage insn prevent the compiler from re-arranging
> > other following instructions ?
> > 
> > In fact, the two emit_insn() need to be seen as one instruction with
> > the compiler free to re-arrange other instructions around it.
> > 
> > This is needed to implement "mulsidi3" where the hardware use a second
> > instruction to return the high-part of a multiplication result, and
> > that second instruction needs to be issued immediately after the first
> > instruction which return the low-part of the multiplication. Currently
> > this is what is used:

You would normally then write both asm instructions as one template,
something like

  "mul %3,%1,%2\;mulh %4,%1,%2"

where then you make operands[3] and operands[4] the low resp. high SImode
part of the result.

If you have something like traditional MIPS, where you have mflo and mfhi
instructions to get the result into GPRs, you probably should look at how
the mips port does things -- including the r4000 workaround in
"<u>mulsidi3_32bit_r4000".  You may not want constraints for the MD regs
(the mul result), and expand to the hard registers directly.

> > What is needed is for the two emit_insn() to be seen as one
> > instruction with the compiler free to re-arrange other instructions
> > around it.
> > 
> > Is there a better way than the blockage insn to achieve the above ?
> In general if you find yourself needing to force two insns to be
> consecutive like you're doing, then you're probably doing something
> wrong.

Yup :-)

> If you actually need two machine instructions here, then I'd have a
> define_insn which emits both in its output template.  Just describe it
> fully in the RTL.  While it's *generally* best to have define_insns emit
> a single instruction, there are exceptions in almost every port.
> 
> What's definitely not clear to me with your expander above is why you
> have to create two scratch registers then move those into the final
> destination.  That seems odd.

Yeah, I think he needs some fixed registers here, like MD on MIPS and ilk.


Segher



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux