[LLVMbugs] [Bug 10367] Fix the design of GlobalAlias to not require dest type to match source type

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=10367

Rafael Ávila de Espíndola <rafael.espindola at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #16 from Rafael Ávila de Espíndola <rafael.espindola at gmail.com> ---
This was fixed, but not in the way that is discussed in this bug. Instead,
alias are defined to point to arbitrary expressions and we changed all the code
that thought it was possible to, for example, find the aliased symbol.

The argument that convinced me to go this ways is that at the assembly level
expressions like

a = b - c

are sometime valid depending on what b and c are. Before r210062 there was no
way to produce such an expression in LLVM. What we now have is

* GlobalObjecs introduce new data. They are functions or variables. They
normally have a symbol (except for some cases with private linkage).
* GlobalAliases define a label pointing somewhere. At the LLVM level it is not
possible to know if the expression defining the location is valid or not.

I would love to be able to tell if a given expression is valid at the IR level
without dropping support for representing any expression an assembler supports,
but that would be quite a massive change:

With pr10368 we would basically get expressions to represent what is
representable with relocations in object files. In addition to that we would
need to be have a different expression type for all the cases that don't need a
relocation. This would require knowing at the llvm level what section/atom a
label is in.

-- 
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/20140603/b93dec38/attachment.html>