On Fri, Dec 21, 2018 at 06:35:14PM +0100, Richard Biener wrote: > 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.
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
