[PATCH] Enhance ASAN_CHECK optimization
Jakub Jelinek
jakub@redhat.com
Wed Nov 26 09:59:00 GMT 2014
On Tue, Nov 25, 2014 at 08:06:00PM +0300, Yury Gribov wrote:
> +/* Traits class for tree hash maps below. */
> +
> +struct tree_map_traits : default_hashmap_traits
> +{
> + static inline hashval_t hash (const_tree ref)
> + {
> + return iterative_hash_expr (ref, 0);
> + }
> +
> + static inline bool equal_keys (const_tree ref1, const_tree ref2)
> + {
> + return operand_equal_p (ref1, ref2, 0);
> + }
Formatting. The {} should be indented like static and return 2 columns to
the right of that.
> @@ -281,37 +316,46 @@ maybe_optimize_asan_check_ifn (struct sanopt_ctx *ctx, gimple stmt)
>
> gimple_set_uid (stmt, info->freeing_call_events);
>
> - auto_vec<gimple> &v = ctx->asan_check_map.get_or_insert (ptr);
> - if (v.is_empty ())
> + auto_vec<gimple> *ptr_checks = &ctx->asan_check_map.get_or_insert (ptr);
> + gimple g = maybe_get_dominating_check (*ptr_checks);
> +
> + tree base_addr = maybe_get_single_definition (ptr);
> + auto_vec<gimple> *base_checks = NULL;
> + if (base_addr)
> {
> - /* For this PTR we don't have any ASAN_CHECK stmts recorded, so there's
> - nothing to optimize yet. */
> - v.safe_push (stmt);
> - return false;
> + base_checks = &ctx->asan_check_map.get_or_insert (base_addr);
> + /* Original pointer might have been invalidated. */
> + ptr_checks = ctx->asan_check_map.get (ptr);
> }
For base_addr computation, you don't really need g or ptr_checks,
do you? So why not move the:
auto_vec<gimple> *ptr_checks = &ctx->asan_check_map.get_or_insert (ptr);
gimple g = maybe_get_dominating_check (*ptr_checks);
lines below the if?
> @@ -404,10 +445,7 @@ sanopt_optimize_walker (basic_block bb, struct sanopt_ctx *ctx)
> basic_block son;
> gimple_stmt_iterator gsi;
> sanopt_info *info = (sanopt_info *) bb->aux;
> - bool asan_check_optimize
> - = (flag_sanitize & SANITIZE_ADDRESS)
> - && ((flag_sanitize & flag_sanitize_recover
> - & SANITIZE_KERNEL_ADDRESS) == 0);
> + bool asan_check_optimize = (flag_sanitize & SANITIZE_ADDRESS) != 0;
>
> for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi);)
> {
I'm afraid I'm not convinced about this hunk. If asan (kernel-address) is
recovering, I don't see a difference from not reporting two different
invalid accesses to the same function and not reporting two integer
overflows in the same function, at least if they have different location_t.
Jakub
More information about the Gcc-patches
mailing list