On May 21, 2019 5:17:43 PM GMT+02:00, Jeff Law <l...@redhat.com> wrote:
>On 5/21/19 8:37 AM, Jan Hubicka wrote:
>>> And that should be done at RTL creation time instead of
>>> repeatedly over and over. Like with the following.
>>>
>>> Bootstrap / regtest on x86_64-unknown-linux-gnu in progress.
>>
>> Thanks,
>> for TBAA stats I now get
>>
>> Alias oracle query stats:
>> refs_may_alias_p: 3022975 disambiguations, 3321454 queries
>> ref_maybe_used_by_call_p: 6451 disambiguations, 3048555 queries
>> call_may_clobber_ref_p: 817 disambiguations, 817 queries
>> aliasing_component_ref_p: 187 disambiguations, 16103 queries
>> TBAA oracle: 1452502 disambiguations 2956630 queries
>> 550659 are in alias set 0
>> 576739 queries asked about the same object
>> 0 queries asked about the same alias set
>> 0 access volatile
>> 260391 are dependent in the DAG
>> 116339 are aritificially in conflict with void *
>>
>> So some improvement from original (but less great than with my wrong
>> patch):
>>
>> refs_may_alias_p: 3027850 disambiguations, 3340416 queries
>> ref_maybe_used_by_call_p: 6451 disambiguations, 3053430 queries
>> call_may_clobber_ref_p: 817 disambiguations, 817 queries
>> aliasing_component_ref_p: 151 disambiguations, 12565 queries
>> TBAA oracle: 1468434 disambiguations 3010778 queries
>> 550723 are in alias set 0
>> 614261 queries asked about the same object
>> 0 queries asked about the same alias set
>> 0 access volatile
>> 260983 are dependent in the DAG
>> 116377 are aritificially in conflict with void *
>My recollection of the stack slot issue is that when objects from
>different scopes share a slot we can end up reordering their accesses.
>So we might have
>
> {
> int x;
> }
>
> {
> long y;
> }
>
>Assume x & y are addressable for some reason. A read of x at the end
>of
>the first scope might get moved after a store to y in the second scope
>because we think the two objects can't alias.
Of course the GCC memory model doesn't allow such code motion. For anti
dependences you may not use TBAA.
But yes, we had bugs in this area in the past.
Richard.
>
>IIRC this was particularly problematical with aggressive inlining where
>stack slot sharing is important to keep stack usage down in the kernel.
>
>jeff
