llvm dev - Jan 2019 - Aliasing rules difference between GCC and Clang

Hi Ivan,

> As to my own patches pending publication, they are all for the new 
> TBAA format, which you said would be of no help in your case.
>
I actually thought they would help, but merely suggested an intermediate 
step while waiting for those further improvements you are working on. I 
would be happy to try your patches and evaluate if it helps my test case...

thanks

/Jonas

> Regards,
>
>
> On 22/01/2019 16:02, Jonas Paulsson wrote:
>> CAUTION: This email originated from outside of the organization. Do 
>> not click links or open attachments unless you recognize the sender 
>> and know the content is safe.  If you suspect potential phishing or 
>> spam email, report it to ReportSpam at accesssoftek.com
>>
>> Hi Ivan,
>>
>>
>> On 2019-01-18 10:15, Ivan Kosarev wrote:
>>> IIRC, there were proposals/attempts to represent accesses to array
>>> elements as accesses to their first elements, which can technically
be
>>> encoded with the current TBAA format and thus may work as an
>>> incremental improvement on top of the existing TBAA machinery you
are
>>> looking for. But this may need making sure there will be no
>>> regressions for some tricky cases like those that involve GCC's
type
>>> punning and changing effective types within unions and in dynamic 
>>> memory.
>>>
>> It would be interesting for me to apply such a patch and evaluate if it
>> really helps my test case. I would much appreciate any links to (or
>> files of) your patches and the attempts you mentioned above.
>>
>> Thanks,
>>
>> Jonas
>>
>>
>

Hi, Jonas,

I see. In that case I think you could just give the new TBAA a try by 
adding the cc1's  -new-struct-path-tbaa option and seeing if it does 
what you need. The support for member arrays is already there, see 
/tools/clang/test/CodeGen/tbaa-array.cpp . That would also give us some 
more testing (which we need very much), and then resolve issues as we 
go. The previously mentioned local patches pending publishing are 
actually supposed to just fix some special cases. IIRC, the only major 
part we are still missing is the proper support for unions. An attempt 
to support them can be seen at <https://reviews.llvm.org/D39455>, but 
turned out it doesn't implement exactly what we are after with TBAA and 
unions, so this needs some more work.

Regards,


On 25/01/2019 17:44, Jonas Paulsson wrote:
> Hi Ivan,
>
>
>> As to my own patches pending publication, they are all for the new 
>> TBAA format, which you said would be of no help in your case.
>>
> I actually thought they would help, but merely suggested an 
> intermediate step while waiting for those further improvements you are 
> working on. I would be happy to try your patches and evaluate if it 
> helps my test case...
>
> thanks
>
> /Jonas
>
>
>> Regards,
>>
>>
>> On 22/01/2019 16:02, Jonas Paulsson wrote:
>>> CAUTION: This email originated from outside of the organization. Do
>>> not click links or open attachments unless you recognize the sender
>>> and know the content is safe.  If you suspect potential phishing or
>>> spam email, report it to ReportSpam at accesssoftek.com
>>>
>>> Hi Ivan,
>>>
>>>
>>> On 2019-01-18 10:15, Ivan Kosarev wrote:
>>>> IIRC, there were proposals/attempts to represent accesses to
array
>>>> elements as accesses to their first elements, which can
technically be
>>>> encoded with the current TBAA format and thus may work as an
>>>> incremental improvement on top of the existing TBAA machinery
you are
>>>> looking for. But this may need making sure there will be no
>>>> regressions for some tricky cases like those that involve
GCC's type
>>>> punning and changing effective types within unions and in
dynamic
>>>> memory.
>>>>
>>> It would be interesting for me to apply such a patch and evaluate
if it
>>> really helps my test case. I would much appreciate any links to (or
>>> files of) your patches and the attempts you mentioned above.
>>>
>>> Thanks,
>>>
>>> Jonas
>>>
>>>
>>
>

Hi Ivan,
>
> I see. In that case I think you could just give the new TBAA a try by 
> adding the cc1's  -new-struct-path-tbaa option and seeing if it does 
> what you need. 
Unfortunately, it seems that the type DAG does not get any new 
base-nodes for the struct types. The only difference I can see is that 
there seems to be a size-field in the TBAA nodes as well now. So it 
seems that the two struct types still are may-alias...

I supposed I need to pass -new-struct-path-tbaa to all the -cc1 
invocations, so I first ran clang with -save-temps -v, and then reran 
all of them while adding the option as well. Did I do something wrong or 
miss anything?

/Jonas

Program:

typedef struct {
    double c[3][3];
} MATRIX_TY;

typedef struct {
    double c[3];
} VECTOR_TY;

double e = 0.0;
MATRIX_TY *s;
VECTOR_TY *v;
int g = 0;
void h() {
    int i = e;
    s->c[0][i] = g;
    v->c[0] = g;
    g = e;
}

Current/normal type DAG:

!2 = !{!3, !3, i64 0}
!3 = !{!"double", !4, i64 0}
!4 = !{!"omnipotent char", !5, i64 0}
!5 = !{!"Simple C/C++ TBAA"}
!6 = !{!7, !7, i64 0}
!7 = !{!"int", !4, i64 0}
!8 = !{!9, !9, i64 0}
!9 = !{!"any pointer", !4, i64 0}

Extended/size aware type DAG (with -new-struct-path-tbaa):

!2 = !{!3, !3, i64 0, i64 8}
!3 = !{!4, i64 8, !"double"}
!4 = !{!5, i64 1, !"omnipotent char"}
!5 = !{!"Simple C/C++ TBAA"}
!6 = !{!7, !7, i64 0, i64 4}
!7 = !{!4, i64 4, !"int"}
!8 = !{!9, !9, i64 0, i64 8}
!9 = !{!4, i64 8, !"any pointer"}