[LLVMdev] DataStructure Analysis ds-aa can not stop when passing mysqld

[hc2428 at columbia.edu]

Quoting Andrew Lenharth <andrewl at lenharth.org>:

Hi Andrew,
     Thanks for your reply. How can I eliminate the inttoptr  
instruction from my software? Can any compile option achieve this  
goal? Or shall I modify the source code in software manually?

Thanks,
Heming

> On Wed, May 13, 2009 at 1:36 PM,  <hc2428 at columbia.edu> wrote:
>> Quoting Chris Lattner <clattner at apple.com>:
>>
>> Dear staff,
>>     I am using the ds-aa to pass mysqld. I compile mysqld 4.0.12
>> statically (compile all libraries statically to the executable) and
>> got the bc file, named it as mysqld.bc3.
>>     I use the command to pass:
>>
>> opt -load <poolalloc install dir>/lib/libLLVMDataStructure.so -ds-aa
>> mysqld.bc3 -print-alias-sets -disable-output
>>
>>     However, I got a lot of "cast in ... " on output screen like this:
>>
>> cast in strxnmov
>>         %13 = inttoptr i32 %10 to i8*           ; <i8*> [#uses=1]
>>
>>     In addition, and pass can not stop for a long time, and the last
>> output is the "cast in ... " as above.
>
> inttoptr casts are very bad for alias analysis.  DSA has some code in
> it these days to try to track common inttoptr idioms, but this code
> likely doesn't scale well.
>
> Andrew
>
>> Thanks,
>> Heming
>>
>>
>>>
>>> On May 13, 2009, at 7:22 AM, Stripf, Timo wrote:
>>>
>>>> Hi all,
>>>>
>>>> i?m working atm on a backend for a processor architecture that is
>>>> capable of storing the carry flag of ADDC in an 1-bit register
>>>> class. So I tried to lower the ADDC instruction to generate two
>>>> register values as result. On the tablegen description of the
>>>> instruction i came across the tablegen restriction that only one
>>>> output result of one instruction is possible:
>>>>
>>>>  assert(NumResults <= 1 &&
>>>>         "We only work with nodes with zero or one result so far!");
>>>>
>>>> So my question is now how much work it would be to remove this
>>>> restriction in tablegen. What do I have to take into consideration?
>>>>
>>>
>>> I don't know offhand, but this would be a very welcome improvement!
>>>
>>> -Chris
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>