Changes in type-mapping-bug2.ll en Copyright 2015 Java 7b1d7937 - Reland "Change the X86 datalayout to add three address spaces http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/LTO/X86/type-mapping-bug2.ll#7b1d7937 Reland "Change the X86 datalayout to add three address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers."This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5.Original review at https://reviews.llvm.org/D64931.Review for added fix at https://reviews.llvm.org/D66843.llvm-svn: 371568 List of files: /llvm-project-15.0.7/llvm/test/LTO/X86/type-mapping-bug2.ll Tue, 10 Sep 2019 23:15:38 +0000 Amy Huang <akhuang@google.com> 57076d31 - Revert "Change the X86 datalayout to add three address spaces for 32 bit signed," http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/LTO/X86/type-mapping-bug2.ll#57076d31 Revert "Change the X86 datalayout to add three address spaces for 32 bit signed,"This reverts commit r370083 because it caused check-lld failures onsanitizer-x86_64-linux-fast.llvm-svn: 370142 List of files: /llvm-project-15.0.7/llvm/test/LTO/X86/type-mapping-bug2.ll Wed, 28 Aug 2019 01:08:54 +0000 Vlad Tsyrklevich <vlad@tsyrklevich.net> 1299945b - Change the X86 datalayout to add three address spaces for 32 bit signed, http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/LTO/X86/type-mapping-bug2.ll#1299945b Change the X86 datalayout to add three address spaces for 32 bit signed,32 bit unsigned, and 64 bit pointers.llvm-svn: 370083 List of files: /llvm-project-15.0.7/llvm/test/LTO/X86/type-mapping-bug2.ll Tue, 27 Aug 2019 17:46:53 +0000 Amy Huang <akhuang@google.com> 34b91122 - IRMover: Account for matching types present across modules http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/LTO/X86/type-mapping-bug2.ll#34b91122 IRMover: Account for matching types present across modulesSummary:Due to uniqueing of DICompositeTypes, it's possible for a type from onemodule to be loaded into another earlier module without being renamed.Then when the defining module is being IRMoved, the type can be used asa Mapping destination before being loaded, such that when it's requestedusing TypeMapTy::get() it will fail with an assertion that the type is asource type when it's actually a type in both the source anddestination modules. Correctly handle that case by allowing a non-opaquenon-literal struct type be present in both modules.Fix for PR37684.Reviewers: pcc, tejohnsonReviewed By: pcc, tejohnsonSubscribers: tobiasvk, mehdi_amini, steven_wu, llvm-commits, kccDifferential Revision: https://reviews.llvm.org/D47898llvm-svn: 335145 List of files: /llvm-project-15.0.7/llvm/test/LTO/X86/type-mapping-bug2.ll Wed, 20 Jun 2018 16:50:56 +0000 Vlad Tsyrklevich <vlad@tsyrklevich.net>