This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Fix PR rtl-optimization/87727

On Fri, Dec 21, 2018 at 04:55:28PM +0100, Richard Biener wrote:
> On Fri, Dec 21, 2018 at 4:25 PM Vladimir Makarov <> wrote:
> > On 12/20/2018 06:14 PM, Peter Bergner wrote:
> > > On 12/20/18 4:41 PM, Jeff Law wrote:
> > >> On 12/20/18 2:30 PM, Peter Bergner wrote:
> >    I am just saying that you need at least have cost for each insn
> > alternative (may be sub-targets).  Although some approximation can be
> > possible (like insns number generated from the alternative or even their
> > size).

For RISC targets, most instructions have exactly the same cost (and all
have the same size, or just a few sizes if you look at thumb etc.)

> A further away (in pass distance) but maybe related project is to
> replace the current "instruction selection" (I'm talking about RTL
> expansion)

In current GCC the instruction selection is expand+combine really, and
more the latter even, for well-written backends anyway.  Most "smarts"
expand does does only get in the way, even.

> with a scheme that works on (GIMPLE) SSA.  My
> rough idea for prototyping pieces would be to first do this
> completely on GIMPLE by replacing a "instruction" by
> a GIMPLE asm with an "RTL" body (well, that doesn't have to
> be explicit, it just needs to remember the insn chosen). The
> available patterns are readily available in the .md files, we
> just need some GIMPLE <-> RTL translation of the operations.
> In the end this would do away with our named patterns
> for expansion purposes.

That sounds nice :-)

Do you see some way we can transition to such a scheme bit by bit, or
will there be a flag day?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]