On Wed, May 15, 2024 at 4:40 PM Andrew Pinski via Gcc <gcc@gcc.gnu.org> wrote: > > Hi all, > This is an RFC more than anything and I will be implementing the ideas > here. So thinking about how to improve code generation in general and depend > less on RTL passes (like combine) to do some instruction selection. > So there are 2 ways of implementing this but both involve adding optabs. > For the proposal that we decide on going forward with, I will write it up in > a more generic form and place it up on the wik so folks can follow the same > pattern of this going forward. And if I implement proposal 2, I will make > sure the internals document is updated for each item too. > > Proposal 1 (improve expand): > * Add an optab for andnot (`a & ~b`) > * Use TER to match the andnot pattern and and see if there is a optab for it > and expand it using the optab. > * Use TER to pattern match `((A ^B) & C) ^ B` and expand it as `(A&C) | (B & > ~C)` using the optab (if it exist); should we do some cost check here or > assume the optab is the same cost as bit_and? > > Proposal 2 (use math-opt/ISEL) > * Add an optab for andnot (`a & ~b`) [same as above] > * Add an internal function for andnot > * Create a subpass of math-opt (or isel) that uses a new math-and-simplify > like format to create the internal function for the simple `a & ~b` if there > is an optab > * Do a similar thing for `((A ^B) & C) ^ B` to use the new internal function. > > The pros and cons of each proposal: > * pros of proposal 1: > ** does not need much refactoring or new code added > ** patches would be smaller to review > ** Patches could be implemented within a week > * cons of proposal 1: > ** keeps around TER longer > ** does not scale for additional changes > ** need manual matching since TER has its own rules > ** Can't use ranges due to the way CFG is in transition between Gimple and RTL > > * pros of proposal 2: > ** Can be used to simplify expand later on > ** Easier to add new rules via match syntax > *** can still use manual matching like the current math-opt pass is done > ** Start removal of TER > ** Can use ranger much easier > * cons of proposal 2: > ** genmatch will need to change > ** patches will take a month to write > > > I like proposal 2 better than proposal 1 since it allows for cleanups later > on. > I think about starting this in July if folks think proposal 2 is the way > forward.
Proposal 2 is the way forward. I'm not sure why you need to change genmatch though? We are talking about target independent optabs so you should at least be able to add (match ...) rules to match.pd and use those from ISEL to cobble up direct-optab IFNs when they are supported. What you'd need to do "manually" is clean up dead feeding stmts though that can be easily done with worklist DCE seeded by cobbled up operands of the root and select defining stmts - is that collection what you want to change genmatch for? Of course putting optab matchers into a separate .pd file would be nice as well, but that should be possible with some Makefile hacking. Richard. > Thanks, > Andrew Pinski
