[RFC] New optab for `a&~b` (and future expand improvements)
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. Thanks, Andrew Pinski
Re: [RFC] New optab for `a&~b` (and future expand improvements)
On Wed, May 15, 2024 at 4:40 PM Andrew Pinski via Gcc 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
Re: [RFC] New optab for `a&~b` (and future expand improvements)
Hi! On Wed, May 15, 2024 at 02:39:12PM +, Andrew Pinski via Gcc wrote: > * Add an optab for andnot (`a & ~b`) RTL can just as easily recognise (AND (NOT (...))), if Gimple has problems with that that is just a deficiency in Gimple. RTL only cares about what an expression *means*, ans perhaps sometimes about canonical forms. Never about silly naming things. In RTL you never have redundant expressions things like "andnot". Such things can at best get in the way always, and more likely be immediately detrimental. Segher
gcc-11-20240515 is now available
Snapshot gcc-11-20240515 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20240515/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision dde786aa4ea8fd894b5a87822854c7747050a237 You'll find: gcc-11-20240515.tar.xz Complete GCC SHA256=c2c50fd3322c67cc02367af7168c25a670f8d5d24aed55a49c258c1cba5a3b6b SHA1=923bc9d9b98b163d29a7cfe1783abb705391f75a Diffs from 11-20240508 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
