On 10/5/26 11:56 PM, Aldy Hernandez wrote:
[I ran gcov over the DOM pass + scoped tables to see if there was any
low hanging fruit to be removed. This hardly anything, but this fell
out.]
Clean up some places where we're scanning for constants on the LHS of
a binary operation. This never gets tickled as gimple keeps constants
on the RHS. Don't touch the MINUS_EXPR case, as substraction is not
commutative.
Likewise for record_edge_info where we have an arm for a conditional
with the constant on the left, with a comment saying copy propagation
can produce one. However, fold_stmt canonicalizes the operand order
of a GIMPLE_COND, so by the time record_edge_info gets it, the
constant is on the right.
Assembly is identical with and without this change over a corpus of
.ii files from a stage1 bootstrap and over the LAPACK Fortran sources,
and gcov shows the removed code never executes over those files nor
the C, C++ and Fortran testsuites.
OK?
litt
gcc/ChangeLog:
* tree-ssa-dom.cc (edge_info::derive_equivalences): Remove the
constant-first arms of the PLUS_EXPR and EQ_EXPR cases.
(record_edge_info): Remove the arm for a constant first operand.
My recollection was these cases happened internally within DOM and if
they persisted beyond the limits of DOM they'd be canonicalized. They
may have been limited to showing up with jump threading, but I wouldn't
bet the farm on that.
Anyway, if you're not seeing them show up in your testing, then let's
kill that little bit of code. Everything helps here.
jeff