[LLVMdev] Strange pointer aliasing behaviour

Andrew Haley aph at redhat.com
Thu Jun 17 10:42:30 PDT 2010


On 06/17/2010 06:19 PM, Jeffrey Yasskin wrote:
> On Thu, Jun 17, 2010 at 12:22 AM, Eli Friedman <eli.friedman at gmail.com> wrote:
>> On Wed, Jun 16, 2010 at 11:14 PM, Pierre C <lists at peufeu.com> wrote:
>>>> There are essentially two ways to "solve" this issue: one is
>>>> type-based alias analysis, i.e. assuming "double" and "int" don't
>>>> alias; LLVM doesn't implement this at the moment.  The other is to
>>>> attempt to analyze the loop and prove that %indvar.i is never
>>>> negative; LLVM doesn't implement anything like this at the moment
>>>> either.
>>>>
>>>> -Eli
>>>
>>> Actually I think it's much simpler than that...
>>>
>>> http://llvm.org/releases/1.3/docs/AliasAnalysis.html#basic-aa
>>>
>>> it says says "Different fields of a structure do not alias."
>>>
>>> This is the case here : we have two different fields of a struct however it
>>> mistakenly thinks they alias.
>>
>> Consider a case like the following:
>> struct X { int a; int b[10]; };
>> int f(struct X* a) { a->b[-1] = 1; return a->a; }
>>
>> This is technically illegal code, but various programs depend on
>> constructs like this working.
> 
> I don't know if it's illegal, but this is how libstdc++'s string
> implementation finds its header data. std::string stores a pointer
> directly to the character data (making subscripting slightly faster),
> and then subtracts the size of the header when it needs to do any
> bookkeeping.

Character types are special: they can alias everything.  if this weren't
the case you couldn't write malloc().

> Do you have a reference to the standard that makes it undefined?

Several places, but 6.3.2.3 of C99 is the most important: it lists all
the legal pointer conversions.

Andrew.



More information about the llvm-dev mailing list