[llvm-dev] Question on llvm-diff tool

Pete Swain via llvm-dev llvm-dev at lists.llvm.org
Fri Jun 18 01:40:07 PDT 2021


when diffing, perhaps we should compare the actual representation, tying
same-name-and-structure objects together, though types arise from different
parses, rather than the usually tighter scoping

On Fri, Jun 18, 2021 at 12:47 AM Bill Wendling <morbo at google.com> wrote:

> Some context. Here are the type definitions and global definition:
>
>   %struct.vmcs_layout = type { i32, [2048 x %struct.vmcs_entry] }
>   %struct.vmcs_entry = type { i16, i16 }
>     ...
>   @vmcs_layout = internal global %struct.vmcs_layout zeroinitializer,
> align 4, !dbg !10400
>
> It seems like it's applying the ".663" suffix because of a name clash with
> the other type.
>
> -bw
>
> On Thu, Jun 17, 2021 at 5:00 PM Yonghyun Hwang <yonghyun at google.com>
> wrote:
>
>> Hello,
>>
>> I'm using the 'llvm-diff' tool to diff two llvm assembly files. While
>> doing that, I've observed that the 'llvm-diff' tool shows lots of diffs
>> even when the same assembly files are given as command line arguments. For
>> example, if we run
>>
>> $ llvm-diff test.ll test.ll
>>
>> 'llvm-diff' shows lots of diffs for "static" global variables. This is an
>> example.
>>
>> // in test.c
>> static struct vmcs_layout vmcs_layout;
>>
>> output for 'llvm-diff' is as follows.
>>
>>     >   %3 = load i32, i32* getelementptr inbounds (%
>> *struct.vmcs_layout.663*, %struct.vmcs_layout.663* @vmcs_layout, i64 0,
>> i32 0), align 4
>>     <   %3 = load i32, i32* getelementptr inbounds (%*struct.vmcs_layout*,
>> %struct.vmcs_layout* @vmcs_layout, i64 0, i32 0), align 4
>>
>> The difference is a suffix, 663. Is this behavior intentional for
>> 'llvm-diff'? If it's intentional, how can I update 'llvm-diff' tool to see
>> "no" diffs for the same .ll file?
>>
>> Thank you,
>> Yonghyun
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210618/500cb2a9/attachment.html>


More information about the llvm-dev mailing list