[llvm-dev] May IR types be merged by llvm-link?

[Friedman, Eli via llvm-dev]

On 12/7/2017 2:16 AM, Serge Pavlov via llvm-dev wrote:
> Hi all,
>
> There is some uncertainty in the concept of LLVM IR, which results in 
> unexpected IR in some cases. The problem description is here: 
> https://reviews.llvm.org/D40567#943747. In short, llvm-link tries to 
> merge an opaque type with its definition, using type name for that. 
> Clang uses the same name for all specializations of a class template, 
> so in this case llvm-link chooses arbitrary type as a definition. As a 
> result the opaque type is mapped to wrong type in IR.
>
> The question here is whether the opaque type resolution made by 
> llvm-link is a correct operation, which in turn depends on what source 
> language objects are represented in IR.  Variables and function must 
> exist in IR because these are entities directly represented in object 
> files, but types do not have similar requirement. There are at least 
> two viewpoints on which entities of source language should be 
> represented in IR.
>
> Case 1
>
> LLVM IR is a functional equivalent of the compiled program. It tries 
> to preserve information about externally visible objects (variables, 
> functions) that may be used in operation on IR modules. In particular, 
> as C++ defines rules of equivalence for types defined in different 
> translation units, and these rules make opaque type resolution 
> possible, the IR must have an equivalent for C++ type.
>

This simply doesn't reflect reality.  Opaque and identified structure 
types exist to make IR easier to understand for humans; the names don't 
affect the semantics of any IR instruction, and transformations 
frequently throw away types to perform optimizations.

> In this case clang must provide appropriate IR type identification, so 
> that the same types in different translation units can be recognized. 
> It can be made by assigning each type a unique name.
>

clang should try to do this anyway; not because we have to, but just to 
make IR easier to read.

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171208/22acf9ef/attachment.html>