On Mon, 11 Jan 2021, Jeff Law wrote:
On 1/9/21 5:43 PM, Maciej W. Rozycki wrote:
On Mon, 21 Dec 2020, Jakub Jelinek wrote:
This patch adds the ~(X - Y) -> ~X + Y simplification requested
in the PR (plus also ~(X + C) -> ~X + (-C) for constants C that can
be safely negated.
This regresses VAX code produced by the cmpelim-eq-notsi.c test case (and
its similar counterparts) with the `vax-netbsdelf' target.
The point of the match.pd changes is to canonicalize GIMPLE on some form
when there are several from GIMPLE POV equivalent or better forms of writing
the same thing. The advantage of having one canonical way is that ICF,
SCCVN etc. optimizations can then understand the different forms are
equivalent.
Fair enough, though in cases like this I think it is unclear which of the
two forms is going to be ultimately better, especially as it may depend on
the exact form of the operands used, e.g. values of any immediates, so I
think a way to make the reverse transformation (whether to undo one made
here or genuinely) needs to be available at a later compilation stage.
One size doesn't fit all.
With this in mind...
So in this case the number of operations are the same before/after and
parallelism is the same before/after, register lifetimes, etc. I doubt
either form is particularly better suited for CSE or gives better VRP
data, etc. The fact that we can't always do ~(X +C) -> ~X + -C
probably argues against that form ever so slightly.
If another form is then better for a particular machine, it should be done
either during expansion (being able to produce both RTLs and computing their
costs), or during combine with either combine splitters or
define_insn_and_split in the backend, or, if it can't be done in RTL, during
the isel pass.
Hmm, maybe it has been discussed before, so please forgive me if I write
something silly, but it seems to me like this should be done in a generic
way like match.pd so that all the targets do not have to track the changes
made there and then perhaps repeat the same or similar code each. So I
think it would make sense to make a change like this include that reverse
transformation as well, so that ultimately both forms are tried with RTL,
as there is no clear advantage to either here.
The idea we've kicked around in the past was to use the same syntax as
match.pd, but have it be target dependent to reform expressions in ways
that are beneficial to the target and have it run at the end of the
gimple/ssa pipeline. Nobody's implemented this though.
Yes. And while a gimple-to-gimple transform is indeed quite simple
to make eventually a match.pd-like gimple-to-RTL would be more
useful in the end. Note RTL can eventually be emulated close enough
via the use of internal functions mapping to optabs. But still
complex combined instructions will need expander help unless we
expose all named instruction RTL patterns as target specific
internal functions to use from that .pd file.
Richard.
jeff
