On Thu, Aug 30, 2018 at 7:39 PM Martin Sebor <msebor@gmail.com> wrote:
On 08/30/2018 11:22 AM, Richard Biener wrote:
On August 30, 2018 6:54:21 PM GMT+02:00, Martin Sebor <msebor@gmail.com> wrote:
On 08/30/2018 02:35 AM, Richard Biener wrote:
On Thu, Aug 30, 2018 at 2:12 AM Martin Sebor <msebor@gmail.com>
wrote:
The attached patch adds code to work harder to determine whether
the destination of an assignment involving MEM_REF is the same
as the destination of a prior strncpy call. The included test
case demonstrates when this situation comes up. During ccp,
dstbase and lhsbase returned by get_addr_base_and_unit_offset()
end up looking like this:
"During CCP" means exactly when? The CCP lattice tracks copies
so CCP should already know that _1 == _8. I suppose during
substitute_and_fold then? But that replaces uses before folding
the stmt.
Yes, when ccp_finalize() performs the final substitution during
substitute_and_fold().
But then you shouldn't need the loop but at most look at the pointer SSA Def to get at the non-invariant ADDR_EXPR.
I don't follow. Are you suggesting to compare
SSA_NAME_DEF_STMT (dstbase) to SSA_NAME_DEF_STMT (lhsbase) for
equality? They're not equal.
No.
The first loop iterates once and retrieves
1. _8 = &pb_3(D)->a;
The second loop iterates three times and retrieves:
1. _1 = _9
2. _9 = _8
3. _8 = &pb_3(D)->a;
How do I get from _1 to &pb_3(D)->a without iterating? Or are
you saying to still iterate but compare the SSA_NAME_DEF_STMT?
I say you should retrieve _8 = &pb_3(D)->a immediately since the
copies should be
propagated out at this stage.