On Thu, Jun 23, 2011 at 10:00 AM, Eric Botcazou <ebotca...@adacore.com> wrote:
>> Is the following patch a reasonable fix for this case?
>
> The lines should be moved to within the first branch of the subsequent "if".
> They aren't needed if the second branch is taken because, in this case, we're
> back to the usual caller-copied scheme where we pass the address of the copy.
>
>> I assume I should add similar code inside emit_library_call_value_1.
>
> Yes, we need the same treatment for 'val' in the MEM_P (val) && !must_copy 
> case
> as the one applied in emit_block_move_hints.
>
>
> But these problems show that there is a slight discrepancy between what dse.c
> really needs (is the address of the variable taken?) and what may_be_aliased
> answers (might the variable be indirectly modified?).  Another viewpoint is to
> say that there is a slight discrepancy between Tree and RTL level when it 
> comes
> to the address-taken property.  Not clear what to do about it so I think that
> we should try this kludgy way and see how it fares.

Yeah, I agree.  Unless we want to really do alias analysis on RTL (and not just
export what the tree level has in some way) let's go forward with this.

So, what's the patch(es) that need approval now?

Thanks,
Richard.

> --
> Eric Botcazou
>

Reply via email to