Peng Yu via llvm-dev
2019-Feb-06 13:39 UTC
[llvm-dev] Not to consolidate two structs with the same data types (but different names) in configure/make tool chain
Hi, I have the following C code. #define PTR_T char * typedef struct objcache { PTR_T data; int cs; /* cache size, number of objects */ int nc; /* number of cache entries */ } sh_obj_cache_t; struct dstack { char *delimiters; int delimiter_depth; int delimiter_space; }; When it is configured/made to generate IR with the following environment variables, CC=clang CXX=clang++ RANLIB=llvm-ranlib CFLAGS=-flto LDFLAGS=-flto\ -fuse-ld=gold\ -Wl\,-plugin-opt=save-temps I see all the variables declared as sh_obj_cache_t in the source code becomes of type %struct.dstack instead of %struct.objcache. sh_obj_cache_t wdcache = {0, 0, 0}; @wdcache = dso_local global %struct.dstack zeroinitializer, align 8, !dbg !1189 If I directly compile the .c file to .ll, I will not see this problem. Is there a way to still use the configure/make toolchain, yet still maintain the original type information instead of consolidating types of the same data? Thanks. -- Regards, Peng
Jeremy Lakeman via llvm-dev
2019-Feb-07 02:24 UTC
[llvm-dev] Not to consolidate two structs with the same data types (but different names) in configure/make tool chain
https://llvm.org/docs/LangRef.html#structure-types Fundamentally, llvm is not designed to preserve details about front end language features. On Thu, 7 Feb 2019 at 00:09, Peng Yu via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Hi, > > I have the following C code. > > #define PTR_T char * > > typedef struct objcache { > PTR_T data; > int cs; /* cache size, number of objects */ > int nc; /* number of cache entries */ > } sh_obj_cache_t; > > struct dstack { > char *delimiters; > int delimiter_depth; > int delimiter_space; > }; > > When it is configured/made to generate IR with the following > environment variables, > > CC=clang CXX=clang++ RANLIB=llvm-ranlib CFLAGS=-flto LDFLAGS=-flto\ > -fuse-ld=gold\ -Wl\,-plugin-opt=save-temps > > I see all the variables declared as sh_obj_cache_t in the source code > becomes of type %struct.dstack instead of %struct.objcache. > > sh_obj_cache_t wdcache = {0, 0, 0}; > > @wdcache = dso_local global %struct.dstack zeroinitializer, align 8, !dbg > !1189 > > If I directly compile the .c file to .ll, I will not see this problem. > > Is there a way to still use the configure/make toolchain, yet still > maintain the original type information instead of consolidating types > of the same data? Thanks. > > -- > Regards, > Peng > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://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/20190207/f914330d/attachment.html>
Peng Yu via llvm-dev
2019-Feb-07 02:55 UTC
[llvm-dev] Not to consolidate two structs with the same data types (but different names) in configure/make tool chain
> https://llvm.org/docs/LangRef.html#structure-typesI don't follow the above link. Could you help explain what it means?> Fundamentally, llvm is not designed to preserve details about front end language features.If directly compile .c to .ll can preserve the original struct information even they are essentially the same, why flto can not? It seems to me that there must be a way to preserve such info if flto is used. -- Regards, Peng
Possibly Parallel Threads
- Not to consolidate two structs with the same data types (but different names) in configure/make tool chain
- How to generate .bc file using configure && make on Mac OS X?
- Is it possible to generate the IR representation with the original macro information?
- How to generate .bc file using configure && make on Mac OS X?
- Four bitcode generated with plugin-opt=save-temps