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? Segher
