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

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,

Sorry for the late answer.

As far as I'm aware, those proposals didn't result in any patches 
published. Here's the original message discussing the approach:

[llvm-dev] RFC: Representing unions in TBAA
http://lists.llvm.org/pipermail/llvm-dev/2017-February/110082.html

Despite its title, it also suggests changes supposed to address the 
issue with representation of array-element accesses.

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.

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,

> 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
>>
>>
>