On Fri, Dec 21, 2018 at 5:25 PM Segher Boessenkool <seg...@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 <vmaka...@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
