llvm dev - Dec 2017 - May IR types be merged by llvm-link?

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.



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.



Case 2



LLVM IR is a low-level representation designed for code generation. Some
information about externally visible objects may be lost, it is expectable.
In particular, IR types belong solely to internal machinery, they have no
relation to types used in source language.



In this case opaque type name resolution made by llvm-link is incorrect
operation and must be removed. Only functions and variables may be merged
and opaque type resolution may occur only as a side-effect of such merge.




It looks like now clang and llvm-link follow different concepts.

I wonder which viewpoint complies with the IR design.

Thanks,
--Serge
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171207/ac123bc2/attachment.html>

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>

Thank you, Eli.


Thanks,
--Serge

2017-12-09 2:03 GMT+07:00 Friedman, Eli <efriedma at codeaurora.org>:
> 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.
>
It means that the case 2 is true, and type merge should be removed. An
operation that essentially depends on the property that is added solely for
reading by humans is not a valid IR transformation.

>
> 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/20171209/0f84eb13/attachment.html>

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>