bah.. wrong reply function
-------- Forwarded Message --------
Subject: Re: [PATCH 2/4] tree-optimization/104288 - Register side
effects during ranger vrp domwalk.
Date: Tue, 8 Feb 2022 09:52:49 -0500
From: Andrew MacLeod <[email protected]>
To: Richard Biener <[email protected]>
On 2/8/22 03:14, Richard Biener wrote:
On Mon, Feb 7, 2022 at 3:32 PM Andrew MacLeod via Gcc-patches
<[email protected]> wrote:
This patch adds the ability to register side effects within a block to
ranger. This is currently only for tracking non-null values.
the rvrp_folder performs a DOM walk and then attempts to simplify and
the fold each stmt during the walk. This patch adds a call to
register_side_effects() to record any effects the stmt might have before
returning.
This checks if the non-null property is set for any ssa-names on the
statement, and if they are, moves the state to only non-null for the
block... This allows us to adjust the property within the block as we
do the DOM walk. All further queries within the block will then come
back as non-null. ALl other queries will be from outside the block, so
they will see the same results anyway.
Unfortunately, none of the non-null routines in gimple.cc appear to work
"in bulk", but rather, on a specific tree-ssa operand request at a
time. For this patch, I need to scan the entire statement looking for
any operand that is nonnull (or the performance impact is awful).
In tree.cc we have get_nonnull_args which you'd pass the
gimple_call_fntype, its expense is allocating a bitmap (if any arg is
nonnull)
which you'd then need to iterate over and free. I think that's an OK
overhead for not duplicating the walk?
I will experiment.
It would be nice to be able to pass an optional bitmap into that
routine.... Since I have bitmap obstacks and temporary bitmaps laying
around.
Would you be OK if I added an optional bitmap pointer to that? no allocs
would be handy I suspect.
I took the code in the various infer_nonnull routines, and packed it all
together into the two routines block_apply_nonnull &&
infer_nonnull_call_attributes, which basically perform the same
functionality as infer_nonnull_range_by_dereference and
infer_nonnull_range_by_attribute, only on all the operands at once. I
think its right, but you may want to have a look. I intend to leverage
this code in GCC13 for a more generalized range_after_stmt mechanism
that will do away with the immediate-use visits of the current non-null
+void
+non_null_ref::block_apply_nonnull (gimple *s)
+{
+ if (!flag_delete_null_pointer_checks)
+ return;
+ if (is_a<gphi *> (s))
+ return;
+ if (gimple_code (s) == GIMPLE_ASM || gimple_clobber_p (s))
+ return;
+ if (is_a<gcall *> (s))
+ {
+ infer_nonnull_call_attributes (as_a<gcall *> (s));
+ return;
+ }
+ walk_stmt_load_store_ops (s, (void *)this, non_null_loadstore,
+ non_null_loadstore);
Both ASM and calls can have pointer dereferences embedded so
I wonder whether you should do the walk_stmt_load_store_ops
anyway. Note that any exceptional control flow (EH or abnormal)
for ASM I just did what infer_nonnull_range_by_dereference does:
if (!flag_delete_null_pointer_checks
|| !POINTER_TYPE_P (TREE_TYPE (op))
|| gimple_code (stmt) == GIMPLE_ASM
|| gimple_clobber_p (stmt))
return false;
if (walk_stmt_load_store_ops (stmt, (void *)op,
check_loadstore, check_loadstore))
ASMs are also skipped in infer_nonnull_range_by_attribute(), and the
rest of that routine only deals with calls.
The calls.. yes, perhaps, it shgould also fall through. I was thinking
that calls were handled by the attribute, but with the || condition it
could be looking for load/stores too.
will not have realized the outputs on a stmt (LHS of call, outputs
of asms), so nonnull carries over only across fallthru or conditional
edges.
I suppose realizing the LHS could be postponed for GCC 13, for
calls you could still walk loads so you get the non-nullness of
aggregate arguments like foo (*p) after the stmt.
But you can of course do all this for GCC 13 only.
The LHS should get covered via the gimple-range-fold mechanism that
produces the range for the LHS. fold_using_range::range_of_call()
handles the calls already:
else if (gimple_call_nonnull_result_p (call)
|| gimple_call_nonnull_arg (call))
r = range_nonzero (type);
DO we handle asms differently somewhere else? the infer() code seems to
skip them completely.
Andrew
