From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20579 invoked by alias); 20 Oct 2007 11:13:35 -0000 Received: (qmail 20423 invoked by uid 48); 20 Oct 2007 11:13:22 -0000 Date: Sat, 20 Oct 2007 11:13:00 -0000 Message-ID: <20071020111322.20422.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug rtl-optimization/33828] Issues with the implementation of code hoisting in gcse.c In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "steven at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-10/txt/msg01797.txt.bz2 ------- Comment #6 from steven at gcc dot gnu dot org 2007-10-20 11:13 ------- Again from gcse.c:compute_transpout(): static void compute_transpout (void) { basic_block bb; unsigned int i; struct expr *expr; sbitmap_vector_ones (transpout, last_basic_block); FOR_EACH_BB (bb) { /* Note that flow inserted a nop a the end of basic blocks that end in call instructions for reasons other than abnormal control flow. */ if (! CALL_P (BB_END (bb))) continue; for (i = 0; i < expr_hash_table.size; i++) for (expr = expr_hash_table.table[i]; expr ; expr = expr->next_same_hash) if (MEM_P (expr->expr)) { if (GET_CODE (XEXP (expr->expr, 0)) == SYMBOL_REF && CONSTANT_POOL_ADDRESS_P (XEXP (expr->expr, 0))) continue; /* ??? Optimally, we would use interprocedural alias analysis to determine if this mem is actually killed by this call. */ RESET_BIT (transpout[bb->index], expr->bitmap_index); } } } Notice the comment about interprocedural alias analysis. That's all nice and dandy, but it would be a start to handle const and pure calls here first. Calls to const and pure functions don't kill MEMs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33828