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

[Ivan Kosarev via llvm-dev]

Hello Eli,

Nonetheless, It seems opaqueness of types affects analyses and code 
generation; see isSized() calls. So maybe it's not purely about readability.


On 08/12/17 21:03, Friedman, Eli via llvm-dev wrote:
> 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
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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