[patch] Fix PR rtl-optimization/87727

[Richard Biener]

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.

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

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.

Richard.

>
> Segher