sepavloff abandoned this revision.
sepavloff added a comment.
The feedback here, in https://reviews.llvm.org/D40508 and in the mail list
(http://lists.llvm.org/pipermail/llvm-dev/2017-December/119585.html)
demonstrates that this is a wrong direction.
Part of this patch is used in
rsmith added a comment.
In https://reviews.llvm.org/D40567#943747, @sepavloff wrote:
> Although code generation (in LTO compilation) might be unaffected by this
> distortions, other applications of IR linking suffer from it. It does not
> allow to implement some checks, validation techniques
sepavloff updated this revision to Diff 125761.
sepavloff added a comment.
Updated patch
- old type names are generated always if --ir-type-names is not specified,
- added new value of --ir-type-names, none, to suppress type names,
- value of --ir-type-names is stored in module properties.
sepavloff added a comment.
Consider a bit more complicated example.
File `common.h`
#ifndef COMMON_H
#define COMMON_H
struct Alarm { };
struct Info { };
template struct Handler;
#endif
File `use-1.cpp`
#include "common.h"
Handler *info;
void set(Handler *e) { info = e; }
sepavloff added a comment.
In https://reviews.llvm.org/D40567#940025, @rsmith wrote:
> What actual problem is this solving? These IR type names exist only for the
> convenience of humans reading the IR, and making them long (potentially
> extremely long) by including template arguments seems
rsmith added a comment.
What actual problem is this solving? These IR type names exist only for the
convenience of humans reading the IR, and making them long (potentially
extremely long) by including template arguments seems likely to hinder that
more than it helps.
sepavloff created this revision.
Herald added subscribers: JDevlieghere, eraman.
If a module contains opaque type and another one contains definition
of equivalent type in sense of C++, `llvm-link` merges these types.
In this procedure it can rely only on type name. An issue arises if
the type is
