[llvm-bugs] [Bug 27866] New: Alias to Linkonce global / canonical representation for Aliases

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=27866

            Bug ID: 27866
           Summary: Alias to Linkonce global / canonical representation
                    for Aliases
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: mehdi.amini at apple.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

I spent some time with Duncan today trying to understand aliases and we came to
the conclusion that:

@a = global i32 0
@b = alias @a

should be equivalent to:

@0 = private i32 0
@a = alias @0
@b = alias @0


We may even consider this as a canonical representation of aliases and have
global-opt actually take care of doing this transformation.

However some behavior is unexpected, right now running llvm-link with the
following IR:

@A = linkonce_odr global i8 1
@B = alias i8, i8* @A

will generate the same IR. It means that linking @B actually introduce the
symbol @A as if the alias is an actual use of the other name. Running
globalopt/global-dce does not change the IR.

However if we "canonicalize" to:

@0 = private global i8 1
@A = linkonce_odr alias i8, i8* @0
@B = alias i8, i8* @0


Then llvm-link generates:

@0 = private global i8 1
@B = alias i8, i8* @0

In this case the symbol @A will *not* be pulled in.
Also, if instead of running llvm-link we run globaldce, we end up with the same
result (@A is dropped).
Finally globalopt is able to turn this IR into:

@B = constant i8 1

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160524/5016605a/attachment.html>