Missing alias definitions

[paulhuggett]

Consider the following IR:

@a = global i32 13, align 4, !repo_definition !0
@b = alias i32, i32* @a
!repo.definitions = !{!0}
!0 = !RepoDefinition(name: "a", digest: [16 x i8] c"aaaaaaaaaaaaaaaa", linkage: external, 
                     visibility: default, pruned: false)

Then:

1. Compile to ELF and dump the symbols from the compiler’s object file:

   % llc -mtriple=x86_64-pc-linux-gnu-elf --filetype=obj -o alias.o alias.ll
   % llvm-objdump --syms alias.o
   
   alias.o:	file format elf64-x86-64
   
   SYMBOL TABLE:
   0000000000000000 l    df *ABS*	0000000000000000 alias.ll
   0000000000000000 g     O .data	0000000000000004 a
   0000000000000000 g     O .data	0000000000000004 b
   % 
   

2. Compile to a repo, and dump the compilation that is produced:

   % llc --mtriple=x86_64-pc-linux-gnu-repo -filetype=obj -o alias.ticket alias.ll
   % pstore-dump --compilation=$(repo-ticket-dump alias.ticket) clang.db
   ---
   
   - file         : 
         path : clang.db
         size : 664
     compilations : 
         - digest      : d3158049b9c53515d7e31fba21052a36
           compilation : 
               members : 
                   - digest     : 61616161616161616161616161616161
                     fext       : { addr: 240, size: 52 }
                     name       : a
                     linkage    : external
                     visibility : default
               path    : /Users/paul/test/alias
               triple  : x86_64-pc-linux-gnu-repo
   ...
   

As you can see, the repo does not contain a definition of 'b'. In the ELF case above both symbols point to the first four bytes of the .data section. This may later result in errors such as ”symbol not found” from the linker. Fully replicating the ELF output (with multiple symbols pointing to the same data in the output) will also require issue #64 to be resolved.

[paulhuggett]

For the sake of completeness, there is an identical problem with functions:

define i32 @c() !repo_definition !0 {
entry:
  ret i32 64
}

@d = alias i32(), i32()* @c

!repo.definitions = !{!0}
!0 = !RepoDefinition(name: "c", digest: [16 x i8] c"cccccccccccccccc", linkage: external,
                     visibility: default, pruned: false)

Compile and dump the two versions:

% llc -mtriple=x86_64-pc-linux-gnu-elf --filetype=obj -o alias.o alias.ll
% llvm-objdump --syms alias.o

alias.o:	file format elf64-x86-64

SYMBOL TABLE:
0000000000000000 l    df *ABS*	0000000000000000 alias.ll
0000000000000000 l    d  .text	0000000000000000 .text
0000000000000000 g     F .text	0000000000000006 c
0000000000000000 g     F .text	0000000000000006 d

% llc --mtriple=x86_64-pc-linux-gnu-repo -filetype=obj -o alias.ticket alias.ll
% pstore-dump --compilation=$(repo-ticket-dump alias.ticket) clang.db
---

- file         : 
      path : clang.db
      size : 688
  compilations : 
      - digest      : af913fd9534187d3437dc244a918f2a5
        compilation : 
            members : 
                - digest     : 63636363636363636363636363636363
                  fext       : { addr: 256, size: 54 }
                  name       : c
                  linkage    : external
                  visibility : default
            path    : /Users/paul/test/alias
            triple  : x86_64-pc-linux-gnu-repo
...
% 

[MaggieYingYi]

The issues are caused by the input IR codes. To contain a definition of 'b' or ‘d’ in the section, the RepoDefinitions of ‘b’ and ‘d’ need to be given in the IR codes.

[MaggieYingYi]

Two things need to be clarified:

1. From above IR examples, since 'b' and 'd' don't have the RepoDefinition metadate in the IR, there is no 'b' and 'd' fragments in the compilation in the current implementation.
2. Discussed the issue with Paul, he mentioned/suggested that “If you’re saying that something is missing from the IR then why doesn’t the compiler tell me that?”
   Good point. I think clang should give an error about missing the RepoDefinition for 'b' and 'd'.

[paulhuggett]

From above IR examples, since 'b' and 'd' don't have the RepoDefinition metadate in the IR, there is no 'b' and 'd' fragments in the compilation in the current implementation.

They don’t, but both aliases could have been created as the result of optimization. I don’t know if such optimizations are performed by the compiler ATM, but they’re not too hard to imagine:

int f() { return 1; }
int g() { return 1; }

Could become:

int f() { return 1; }
alias g = f;

(Obviously this second example isn’t legal C!)

We already create hashes for global objects created as a result of optimization. Shouldn’t aliases be handled in the same way?

Futhermore, if we imagine that RepoDefinition metadata is provided, what would happen if the digests given for the two objects (the alias and the aliasee) happened to be different? (This might happen as the result of a bug or an error in hand-written IR).