This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: PR middle-end/43671: [4.4/4.5/4.6 Regression] -fsched2-use-superblocks -m32 produces wrong code with vectorization
On Mon, May 3, 2010 at 9:15 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Sun, May 02, 2010 at 08:59:23PM -0700, H.J. Lu wrote:
>> H.J.
>> ----
>> gcc/
>>
>> 2010-05-02 ?H.J. Lu ?<hongjiu.lu@intel.com>
>>
>> ? ? ? PR middle-end/43671
>> ? ? ? * (get_addr): Don't return an expression if references_value_p
>> ? ? ? returns true.
>
> I don't think this is the right thing to do to fix this bug.
> Of course get_addr callers could be smarter and look at both addresses
> and don't call get_addr blindly if the same VALUE appears on both sides.
> get_addr in the end returns v->locs->loc anyway, and that can of course also
> include stuff referencing VALUEs. ?Your change merely makes the problem
> latent, nothing else.
>
> In the single problematic true_dependence call it is better if
> get_addr wouldn't be called on both sides, as both sides originally contain
> the same VALUE, but there are many other cases where it is desirable and
> gets us to the right base term. ?The problem is that base_alias_check
> returns 0 in this case. ?And that happens because find_base_term
> ine one case (where get_addr did return VALUE 5:* based address) returns
> (address:P bp) and in the other case (address:P sp) and:
> ?/* If one address is a stack reference there can be no alias:
> ? ? stack references using different base registers do not alias,
> ? ? a stack reference can not alias a parameter, and a stack reference
> ? ? can not alias a global. ?*/
> ?if ((GET_CODE (x_base) == ADDRESS && GET_MODE (x_base) == Pmode)
> ? ? ?|| (GET_CODE (y_base) == ADDRESS && GET_MODE (y_base) == Pmode))
> ? ?return 0;
>
> Normally sp and bp based addresses shouldn't alias, the problem is that
> get_addr got through the VALUE where hard frame pointer got initialized
> and in the function prologue .
> VALUE 7:* here has locs sp and (VALUE 5:*) - 16,
> VALUE 5:* here has locs (VALUE 4:*) & -16,
> VALUE 4:* here has locs bp.
>
> The prologue is pushl %ebp; movl %esp, %ebp; andl $-16, %esp; addl $-16, %esp;
>
> I guess we should prevent get_addr from ever expanding some special VALUEs
> set up during prologue (to avoid seeing through prologue actions).
If the PR shows that the false bp/sp disambiguation is the only
case we have to worry about I agree. But - can we easily detect
that case? I see we play some tricks in init_alias_target (), but
I am not very familiar with this code.
Richard.
> ? ? ? ?Jakub
>