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.
jeff
