[llvm-dev] IR with no optimization

Tue Feb 9 15:47:56 PST 2016

Thank you all !
I'm trying to do pointer analysis in terms of original program variables.
I'm planning to look into Clang.

On Tue, Feb 9, 2016 at 1:31 PM, Daniel Berlin <dberlin at dberlin.org> wrote:

> What George said.
>
> If you are trying to do pointer analysis in terms of original program
> variables (IE to issue error messages later or whatever), you should do it
> at the clang level.
>
> If you are trying to do it for optimization, you don't need original
> program variables and they don't help you :)
> You should do it at the LLVM IR level.
>
> CFL-AA is one such pointer analysis already implemented in LLVM.  There
> are other implementations of things like andersen's, etc you can find.
>
>
> On Tue, Feb 9, 2016 at 11:46 AM, George Burgess IV via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Are you doing this to enable optimizations, or to detect bugs? If the
>> former, dealing with LLVM IR is probably your best bet, and you may find
>> this to be helpful: http://llvm.org/docs/AliasAnalysis.html. If the
>> latter, you probably want to hook into clang's StaticAnalyzer. I'm not
>> familiar with whether or not you'd be able to do AA with it, but AFAIK it
>> retains the full C/C++ AST (LLVM IR doesn't), so your diagnostics would
>> likely be a lot better with that. :)
>>
>> On Tue, Feb 9, 2016 at 9:46 AM, Jingyue Wu via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>>
>>> On Tue, Feb 9, 2016 at 9:31 AM, Kai Wang via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> Thanks for the reply.
>>>>
>>>> Yes I'm doing static analysis. I'm trying to do points-to analysis
>>>> actually. I care about whether pointer values point to the same memory
>>>> location. I'm not sure if this is better to be done by Clang or LLVM?
>>>>
>>>
>>> That depends on what interface your analysis is going to expose. If the
>>> users of your pointer analysis are other IR passes, LLVM IR sounds a better
>>> place and you don't need to care about variable names or assignments.
>>>
>>>
>>>>
>>>> How to dump the unoptimized IR? By compiling with -O0?
>>>> Thank you.
>>>>
>>>>
>>>> On Tue, Feb 9, 2016 at 8:20 AM, David Blaikie <dblaikie at gmail.com>
>>>> wrote:
>>>>
>>>>> If you're trying to do source level analysis (questions like "is there
>>>>> an assignment of a variable of this name") it may be better to work up in
>>>>> Clang than down in LLVM - LLVM has no guarantees about names (indeed names
>>>>> on instructions are a compiler debugging feature, not a feature that should
>>>>> be used by any optimization, analysis, etc) or preservation of things like
>>>>> loads/stores.
>>>>>
>>>>> You could dump the unoptimized IR, if you're just trying to do some
>>>>> static analysis rather than an optimization - doesn't matter to you,
>>>>> probably, if it doesn't produce a valid kernel in the end.
>>>>>
>>>>> On Tue, Feb 9, 2016 at 8:09 AM, Kai Wang via llvm-dev <
>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I'm compiling linux kernel with clang. I want to generate IR with no
>>>>>> optimization. However, kernel can only be compile with -O2 instead of -O0.
>>>>>>
>>>>>> Here is the source code snippet:
>>>>>>
>>>>>> struct zone *next_zone(struct zone *zone)
>>>>>>
>>>>>>  {   pg_data_t **pgdat* = zone->zone_pgdat;
>>>>>>
>>>>>> }
>>>>>>
>>>>>> I want to know there is an assignment from "zone" to "pgdat". I'm
>>>>>> trying to iterate "store" instructions in IR.
>>>>>>
>>>>>> When I compile with -O2, I have the following IR:
>>>>>>
>>>>>> define %struct.zone* @next_zone(%struct.zone* readonly %zone) #0 !dbg
>>>>>> !214 {
>>>>>>
>>>>>>         call void @llvm.dbg.value(metadata %struct.zone* %zone, i64 0,
>>>>>> metadata !218, metadata !305), !dbg !326
>>>>>>
>>>>>>         %1 = getelementptr inbounds %struct.zone, %struct.zone*
>>>>>> %zone, i64 0, i32 5, !dbg !327
>>>>>>
>>>>>>         %2 = load %struct.pglist_data*, %struct.pglist_data** %1,
>>>>>> align 8, !dbg !327
>>>>>>
>>>>>>         call void @llvm.dbg.value(metadata %struct.pglist_data* %2,
>>>>>> i64 0, metadata !219, metadata !305), !dbg !328 }
>>>>>>
>>>>>> *Store instruction has been optimized, and no variable name in IR.*
>>>>>>
>>>>>> When I comile with -O0, I have the following IR:
>>>>>>
>>>>>> define %struct.zone* @next_zone(%struct.zone* %zone) #0 !dbg !211 {
>>>>>>
>>>>>>          %1 = alloca %struct.zone*, align 8
>>>>>>
>>>>>>          %pgdat = alloca %struct.pglist_data*, align 8
>>>>>>
>>>>>>          store %struct.zone* %zone, %struct.zone** %1, align 8
>>>>>>
>>>>>>          call void @llvm.dbg.declare(metadata %struct.zone** %1,
>>>>>> metadata !297, metadata !265), !dbg !298
>>>>>>
>>>>>>          call void @llvm.dbg.declare(metadata %struct.pglist_data**
>>>>>> %pgdat, metadata !299, metadata !265), !dbg !302
>>>>>>
>>>>>>          %2 = load %struct.zone*, %struct.zone** %1, align 8, !dbg !
>>>>>> 303
>>>>>>
>>>>>>          %3 = getelementptr inbounds %struct.zone, %struct.zone* %2,
>>>>>> i32 0, i32 5, !dbg !304
>>>>>>
>>>>>>          %4 = load %struct.pglist_data*, %struct.pglist_data** %3,
>>>>>> align 8, !dbg !304
>>>>>>
>>>>>>          *store %struct.pglist_data* %4, %struct.pglist_data** %**pgdat,
>>>>>> align 8, !dbg !302*
>>>>>> There is store instruction. I know there is an assignment. From this
>>>>>> store, I backward traverse until I find variable.
>>>>>> For example, I go through %4->%3->%2->%1->struct.zone. I have
>>>>>> variable name pgdat in IR as well.
>>>>>>
>>>>>> Since kernel can only be compiled with -O2, IR has been optimized a
>>>>>> lot.
>>>>>> Is there any way I can know the variable name and there is an
>>>>>> assignment from "zone" to "pgdat"?
>>>>>>
>>>>>> Thank you!
>>>>>> --
>>>>>> Regards,
>>>>>> Kai
>>>>>>
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> llvm-dev at lists.llvm.org
>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Kai
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>

-- 
Regards,
Kai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160209/316bd9af/attachment-0001.html>