[Bug tree-optimization/89430] A missing ifcvt optimization to generate csel

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:cf39dccf9284d2fd9f9aa7050760adea110c8d88

commit r10-7952-gcf39dccf9284d2fd9f9aa7050760adea110c8d88
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Apr 25 00:10:01 2020 +0200

    cselim: Don't assume it is safe to cstore replace a store to a local
variable with unknown offset [PR94734]

    As the new testcase shows, it is not safe to assume we can optimize
    a conditional store into an automatic non-addressable var, we can do it
    only if we can prove that the unconditional load or store actually will
    not be outside of the boundaries of the variable.
    If the offset and size are constant, we can, but this is already all
    checked in !tree_could_trap_p, otherwise we really need to check for
    a dominating unconditional store, or for the specific case of automatic
    non-addressable variables, it is enough if there is a dominating load
    (that is what those 4 testcases have).  tree-ssa-phiopt.c has some
    infrastructure for this already, see the add_or_mark_expr method etc.,
    but right now it handles only MEM_REFs with SSA_NAME first operand
    and some integral offset.  So, I think it can be for GCC11 extended
    to handle other memory references, possibly up to just doing
    get_inner_reference and hasing based on the base, offset expressions
    and bit_offset and bit_size, and have also a special case that for
    !TREE_ADDRESSABLE automatic variables it could ignore whether something
    is a load or store because the local stack should be always writable.
    But it feels way too dangerous to do this this late for GCC10, so this
    patch just restricts the optimization to the safe case (where lhs doesn't
    trap), and on Richi's request also ignores TREE_ADDRESSABLE bit if
    flag_store_data_races, because my understanding the reason for
    TREE_ADDRESSABLE check is that we want to avoid introducing
    store data races (if address of an automatic var escapes, some other thread
    could be accessing it concurrently).

    2020-04-25  Jakub Jelinek  <jakub@redhat.com>
                Richard Biener  <rguenther@suse.de>

            PR tree-optimization/94734
            PR tree-optimization/89430
            * tree-ssa-phiopt.c: Include tree-eh.h.
            (cond_store_replacement): Return false if an automatic variable
            access could trap.  If -fstore-data-races, don't return false
            just because an automatic variable is addressable.

            * gcc.dg/tree-ssa/pr89430-1.c: Add xfail.
            * gcc.dg/tree-ssa/pr89430-2.c: Add xfail.
            * gcc.dg/tree-ssa/pr89430-5.c: Add xfail.
            * gcc.dg/tree-ssa/pr89430-6.c: Add xfail.
            * gcc.c-torture/execute/pr94734.c: New test.