This is the mail archive of the gcc-patches@gcc.gnu.org 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 06:35:14PM +0100, Richard Biener wrote:
> On Fri, Dec 21, 2018 at 5:25 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> >
> > On Fri, Dec 21, 2018 at 04:55:28PM +0100, Richard Biener wrote:
> > > On Fri, Dec 21, 2018 at 4:25 PM Vladimir Makarov <vmakarov@redhat.com> 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?
> 
> Well, we could do a "pre-expand" GIMPLE instruction selection
> phase doing instruction selection on (parts) of the IL either
> substituting internal-function calls and use direct-optabs for
> later RTL expansion (that would then introduce target-specific
> internal functions) or try using the suggested scheme^Whack
> of using a GIMPLE ASM kind with instead of the asm text
> something that RTL expansion can work with.  The ASM approach
> has the advantage that we could put in constraints to guide RTL
> expansion, avoiding more "magic" (aka recog) there.

Hrm, so a special kind of GIMPLE ASM, let's call it "GIMPLE RTL"...
That sounds good yes!  As an intermediate, of course :-)

> Not sure what the hard part here is, but I guess it might be
> mapping of GIMPLE SSA to .md file define-insn patterns.

Expand does so *much* currently.  Maybe it shouldn't.  But then we
need to move much of what it does to a better place, because not all
of it is useless.

> Or maybe not.  As said, it should be reasonable easy to
> handle it for the standard named patterns which is where
> you could prototype the plumbing w/o doing the .md file
> parsing and matcher auto-generation.


Segher


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