This repository has been archived by the owner on Feb 5, 2019. It is now read-only.
Fixes SjLj preparation step on iOS #8
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When I originally added node RDTSCP_DAG (r207127) I forgot to add a string name for it in method 'getTargetNodeName'. No functional change intended. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210769 91177308-0d34-0410-b5e6-96231b3b80d8
Differential Revision: http://reviews.llvm.org/D4017 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210770 91177308-0d34-0410-b5e6-96231b3b80d8
…P32 and FP64 Summary: To make this work for both AFGR64 and FGR64 register sets, I've had to make the instruction definition consistent with the white lie (that it reads the lower 32-bits of the register) when they are generated by expandBuildPairF64(). Corrected the definition of hasMips32r2() and hasMips64r2() to include MIPS32r6 and MIPS64r6. Depends on D3956 Reviewers: jkolek, zoran.jovanovic, vmedic Reviewed By: vmedic Differential Revision: http://reviews.llvm.org/D3957 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210771 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210772 91177308-0d34-0410-b5e6-96231b3b80d8
Differential Revision: http://reviews.llvm.org/D3866 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210773 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Depends on D3957 Reviewers: jkolek, zoran.jovanovic, vmedic Reviewed By: vmedic Differential Revision: http://reviews.llvm.org/D3958 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210775 91177308-0d34-0410-b5e6-96231b3b80d8
…ailable on MIPS32r6/MIPS64r6 Summary: c.cond.fmt has been replaced by cmp.cond.fmt. Where c.cond.fmt wrote to dedicated condition registers, cmp.cond.fmt writes 1 or 0 to normal FGR's (like the GPR comparisons). mov[fntz] have been replaced by seleqz and selnez. These instructions conditionally zero a register based on a bool in a GPR. The results can then be or'd together to act as a select without, for example, requiring a third register read port. mov[fntz].[ds] have been replaced with sel.[ds] MIPS64r6 currently generates unnecessary sign-extensions for most selects. This is because the result of a SETCC is currently an i32. Bits 32-63 are undefined in i32 and the behaviour of seleqz/selnez would otherwise depend on undefined bits. Later, we will fix this by making the result of SETCC an i64 on MIPS64 targets. Depends on D3958 Reviewers: jkolek, vmedic, zoran.jovanovic Reviewed By: vmedic, zoran.jovanovic Differential Revision: http://reviews.llvm.org/D4003 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210777 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210778 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: We haven't implemented this instruction so we only add a test case. Reviewers: vmedic, zoran.jovanovic, jkolek Reviewed By: jkolek Differential Revision: http://reviews.llvm.org/D4004 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210779 91177308-0d34-0410-b5e6-96231b3b80d8
The patch transforms ABS(NABS(X)) -> ABS(X) NABS(ABS(X)) -> NABS(X) Differential Revision: http://reviews.llvm.org/D4040 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210782 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210783 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Folded mips64-fp-indexed-ls.ll into fp-indexed-ls.ll. To do so, the zext's in mips64-fp-indexed-ls.ll were changed to implicit sign extensions (performed by getelementptr). This does not affect the purpose of the test. Depends on D4004 Reviewers: zoran.jovanovic, jkolek, vmedic Reviewed By: vmedic Differential Revision: http://reviews.llvm.org/D4110 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210784 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: These instructions are not implemented for any MIPS ISA so we only need testcases. Depends on D4110 Reviewers: jkolek, zoran.jovanovic, vmedic Reviewed By: vmedic Differential Revision: http://reviews.llvm.org/D4111 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210786 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Also tightened up the acceptable condition operand for these instructions on MIPS-I to MIPS-III. Support for $fcc[1-7] was added in MIPS-IV. Prior to that only $fcc0 is acceptable. We currently don't optimize (BEQZ (NOT $a), $target) and similar. It's probably best to do this in InstCombine. Depends on D4111 Reviewers: jkolek, zoran.jovanovic, vmedic Reviewed By: vmedic Differential Revision: http://reviews.llvm.org/D4112 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210787 91177308-0d34-0410-b5e6-96231b3b80d8
Moritz's changes have improved codegen a lot, but further testing showed significant correctness problems. Disable by default until these have been worked out. Patch by Moritz Roth! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210789 91177308-0d34-0410-b5e6-96231b3b80d8
…d x, y)) for vectors" This reverts commit r210540, adds a testcase for the regression it caused, and marks the R600 test it was supposed to fix as XFAIL. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210792 91177308-0d34-0410-b5e6-96231b3b80d8
Since removeRegistrationListener is no longer called during static destruction, we can get rid of the pimpl in PassRegistry. This should clean up the code somewhat, increase clarity, and also allows us to put the Lock as a member of the class, instead of as a ManagedStatic. As part of this change, the PassInfo class is moved from PassSupport.h to its own file, to eliminate the otherwise circular header dependency between PassRegistry.h and PassSupport.h Reviewed by: rnk, dblaikie Differential Revision: http://reviews.llvm.org/D4107 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210793 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210794 91177308-0d34-0410-b5e6-96231b3b80d8
This is a minimal change to remove the header. I will remove the occurrences of "using std::error_code" in a followup patch. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210803 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210805 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Target/X86/X86TargetTransformInfo.cpp: In member function ‘virtual unsigned int {anonymous}::X86TTI::getIntImmCost(unsigned int, unsigned int, const llvm::APInt&, llvm::Type*) const’:
lib/Target/X86/X86TargetTransformInfo.cpp:920:60: warning: enumeral and non-enumeral type in conditional expression [enabled by default]
This seems like an unhelpful warning, but there doesnt seem to be a controlling
flag, so add an explicit cast to silence the warning.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210806 91177308-0d34-0410-b5e6-96231b3b80d8
… GDB). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210807 91177308-0d34-0410-b5e6-96231b3b80d8
The syntax for Global Variables in LangRef is missing the initializer. This syntax section was added in r199218 along with changes to the dllexport/dllimport handling, and I guess it was just an oversight to omit the initializer values. I’ve marked the initializer as optional because this syntax is used for both declarations and definitions. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210808 91177308-0d34-0410-b5e6-96231b3b80d8
…e unit DIEs. Turns out that DW_AT_ranges_base attribute sets the offset for DW_AT_ranges values specified in the .dwo file, but not for DW_AT_ranges specified in the skeleton compile unit DIE in the main executable. This is extremely confusing, and would hopefully be fixed in DWARF-5 when it's finalized. For now this behavior makes sense, as otherwise Fission would break DWARF consumers who doesn't know anything about DW_AT_ranges_base. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210809 91177308-0d34-0410-b5e6-96231b3b80d8
…-point arguments." Reverting it because it breaks several tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210810 91177308-0d34-0410-b5e6-96231b3b80d8
Windows on ARM uses COFF/PE which is intrinsically position independent. For the case of 32-bit immediates, use a pair-wise relocation as otherwise we may exceed the range of operators. This fixes a code generation crash when using -Oz when targeting Windows on ARM. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210814 91177308-0d34-0410-b5e6-96231b3b80d8
…rguments. Recommit with fixed argument attribute checking code, which is required to bail out of all the cases we don't handle yet. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210815 91177308-0d34-0410-b5e6-96231b3b80d8
This test case is supposed to xfail, because we do not handle structs or byval arguments. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210816 91177308-0d34-0410-b5e6-96231b3b80d8
…ent info. I'm not sure what it means to set a section for a declaration in another translation unit, but there are some tests in the tree that do it so it seems to be legal now regardless. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210819 91177308-0d34-0410-b5e6-96231b3b80d8
the initializeSubtargetDependencies code to obtain an initialized subtarget and migrate a couple of subtarget using functions to the .cpp file to avoid circular includes. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210822 91177308-0d34-0410-b5e6-96231b3b80d8
Copy what is done for 32-bit already so the order is about the same. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211186 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211187 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211188 91177308-0d34-0410-b5e6-96231b3b80d8
As requested by Hal Finkel, this adds back a test for calls to a known-constant function pointer value, and verifies that the 64-bit SVR4 indirect function call sequence is used. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211190 91177308-0d34-0410-b5e6-96231b3b80d8
Apparently C++ doesn't really have hex floating point constants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211192 91177308-0d34-0410-b5e6-96231b3b80d8
During an indirect function call sequence on the 64-bit SVR4 ABI,
generate code must load and then restore the TOC register.
This does not use a regular LOAD instruction since the TOC
register r2 is marked as reserved. Instead, the are two
special instruction patterns:
let RST = 2, DS = 2 in
def LDinto_toc: DSForm_1a<58, 0, (outs), (ins g8rc:$reg),
"ld 2, 8($reg)", IIC_LdStLD,
[(PPCload_toc i64:$reg)]>, isPPC64;
let RST = 2, DS = 10, RA = 1 in
def LDtoc_restore : DSForm_1a<58, 0, (outs), (ins),
"ld 2, 40(1)", IIC_LdStLD,
[(PPCtoc_restore)]>, isPPC64;
Note that these not only restrict the destination of the
load to r2, but they also restrict the *source* of the
load to particular address combinations. The latter is
a problem when we want to support the ELFv2 ABI, since
there the TOC save slot is no longer at 40(1).
This patch replaces those two instructions with a single
instruction pattern that only hard-codes r2 as destination,
but supports generic addresses as source. This will allow
supporting the ELFv2 ABI, and also helps generate more
efficient code for calls to absolute addresses (allowing
simplification of the ppc64-calls.ll test case).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211193 91177308-0d34-0410-b5e6-96231b3b80d8
Move fp64 fceil tests to fceil64.ll v2: rebase Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211194 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211196 91177308-0d34-0410-b5e6-96231b3b80d8
ARMTargetStreamer implements ConstantPool and AssmeblerConstantPools to keep track of assembler-generated constant pools that are used for ldr-pseudo. When implementing ldr-pseudo for AArch64, these two classes can be reused. So this patch factors them out from ARM target to the general MC lib. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211198 91177308-0d34-0410-b5e6-96231b3b80d8
These deleted definitions had the wrong types. Patch by Alex L! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211199 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211201 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by John Wolf! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211202 91177308-0d34-0410-b5e6-96231b3b80d8
When looking at the 64-bit SVR4 indirect call sequence, I noticed an unnecessary load of r12. And indeed the code says: // R12 must contain the address of an indirect callee. But this is not correct; in the 64-bit SVR4 (ELFv1) ABI, there is no need to load r12 at this point. It seems this code and comment is a remnant of code originally shared with the Darwin ABI ... This patch simply removes the unnecessary load. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211203 91177308-0d34-0410-b5e6-96231b3b80d8
When emitting optimization remarks, we test for the presence of instruction locations by testing for a valid llvm.dbg.cu annotation. This is slightly inefficient because we can simply ask whether the debug location we have is known or not. Additionally, if my current plan works, I will need to remove the llvm.dbg.cu annotation from the IL (or prevent it from being generated) when -Rpass is used without -g. In those cases, we'll want to generate line tables but we will want to prevent code generation from emitting DWARF code for them. Tested on x86_64. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211204 91177308-0d34-0410-b5e6-96231b3b80d8
We do have use cases for the bitcode reader owning the buffer or not, but we always know which one we have when we construct it. It might be possible to simplify this further, but this is a step in the right direction. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211205 91177308-0d34-0410-b5e6-96231b3b80d8
The main point of this class is to provide a cheap object interface to a bitcode file, so it has to be as lazy as possible. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211207 91177308-0d34-0410-b5e6-96231b3b80d8
Thanks to David Majnemer for noticing. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211208 91177308-0d34-0410-b5e6-96231b3b80d8
LLVMGetBitcodeModuleInContext should not take ownership on error. I will try to localize this odd api requirement, but this should get the bots green. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211213 91177308-0d34-0410-b5e6-96231b3b80d8
|
@alexcrichton as discussed. Note that it is based on |
|
Have you submitted this fix upstream yet? We could cherry-pick onto our fork, but we highly prefer that the fix is submitted upstream before applying locally. Maintaining a stack of patches on our private fork becomes infeasible after awhile. This fix seems small enough, and if you need help writing tests (which will likely be required upstream), I'd be more than willing to help out! |
PassRegistry::getPass() is quite heavy since it involves taking a lock and looking up the info in a hashtable.
Rust uses a lot of empty structs internally. That caused problems during SjLj preparation step as it expected that every function argument actually has some data in it which should be either copied/bitcasted. This fix simply skips any action for arguments which have no data inside (structs with zero fields or arrays with zero elements)
alexcrichton
pushed a commit
that referenced
this pull request
Oct 4, 2014
This patch makes the ARM backend transform 3 operand instructions such as 'adds/subs' to the 2 operand version of the same instruction if the first two register operands are the same. Example: 'adds r0, r0, #1' will is transformed to 'adds r0, #1'. Currently for some instructions such as 'adds' if you try to assemble 'adds r0, r0, #8' for thumb v6m the assembler would throw an error message because the immediate cannot be encoded using 3 bits. The backend should be smart enough to transform the instruction to 'adds r0, #8', which allows for larger immediate constants. Patch by Ranjeet Singh. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218521 91177308-0d34-0410-b5e6-96231b3b80d8
alexcrichton
pushed a commit
that referenced
this pull request
Jun 12, 2015
…airs.
Store instructions do not modify register values and therefore it's safe
to form a store pair even if the source register has been read in between
the two store instructions.
Previously, the read of w1 (see below) prevented the formation of a stp.
str w0, [x2]
ldr w8, [x2, #8]
add w0, w8, w1
str w1, [x2, #4]
ret
We now generate the following code.
stp w0, w1, [x2]
ldr w8, [x2, #8]
add w0, w8, w1
ret
All correctness tests with -Ofast on A57 with Spec200x and EEMBC pass.
Performance results for SPEC2K were within noise.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239432 91177308-0d34-0410-b5e6-96231b3b80d8
alexcrichton
pushed a commit
that referenced
this pull request
Jun 16, 2015
These are really immediate DUPs, and suffer from the same problem
with long instructions with a high/2 variant (e.g. smull).
By extending a MOVI (or DUP, before this patch), we can avoid an ext
on the other operand of the long instruction, e.g. turning:
ext.16b v0, v0, v0, #8
movi.4h v1, #0x53
smull.4s v0, v0, v1
into:
movi.8h v1, #0x53
smull2.4s v0, v0, v1
While there, add a now-necessary combine to fold (VT NVCAST (VT x)).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239799 91177308-0d34-0410-b5e6-96231b3b80d8
eddyb
pushed a commit
to eddyb/llvm
that referenced
this pull request
Sep 16, 2015
In vectorized add reduction code, the final "reduce" step is sub-optimal. This change wll combine : ext v1.16b, v0.16b, v0.16b, rust-lang#8 add v0.4s, v1.4s, v0.4s dup v1.4s, v0.s[1] add v0.4s, v1.4s, v0.4s into addv s0, v0.4s PR21371 http://reviews.llvm.org/D12325 Patch by Jun Bum Lim <junbuml@codeaurora.org>! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246790 91177308-0d34-0410-b5e6-96231b3b80d8
alexcrichton
pushed a commit
that referenced
this pull request
Aug 2, 2018
…d VPlan for tests." Memory leaks in tests. http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/6289/steps/check-llvm%20asan/logs/stdio Direct leak of 192 byte(s) in 1 object(s) allocated from: #0 0x554ea8 in operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:106 #1 0x56cef1 in llvm::VPlanTestBase::doAnalysis(llvm::Function&) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/unittests/Transforms/Vectorize/VPlanTestBase.h:53:14 #2 0x56bec4 in llvm::VPlanTestBase::buildHCFG(llvm::BasicBlock*) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/unittests/Transforms/Vectorize/VPlanTestBase.h:57:3 #3 0x571f1e in llvm::(anonymous namespace)::VPlanHCFGTest_testVPInstructionToVPRecipesInner_Test::TestBody() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/unittests/Transforms/Vectorize/VPlanHCFGTest.cpp:119:15 #4 0xed2291 in testing::Test::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc #5 0xed44c8 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11 #6 0xed5890 in testing::TestCase::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28 #7 0xef3634 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43 #8 0xef27e0 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc #9 0xebbc23 in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46 #10 0xebbc23 in main /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:51 #11 0x7f65569592e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0) and more. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@336718 91177308-0d34-0410-b5e6-96231b3b80d8
alexcrichton
pushed a commit
that referenced
this pull request
Aug 2, 2018
…ering"
This reverts commit r337021.
WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x1415cd65 in void write_signed<long>(llvm::raw_ostream&, long, unsigned long, llvm::IntegerStyle) /code/llvm-project/llvm/lib/Support/NativeFormatting.cpp:95:7
#1 0x1415c900 in llvm::write_integer(llvm::raw_ostream&, long, unsigned long, llvm::IntegerStyle) /code/llvm-project/llvm/lib/Support/NativeFormatting.cpp:121:3
#2 0x1472357f in llvm::raw_ostream::operator<<(long) /code/llvm-project/llvm/lib/Support/raw_ostream.cpp:117:3
#3 0x13bb9d4 in llvm::raw_ostream::operator<<(int) /code/llvm-project/llvm/include/llvm/Support/raw_ostream.h:210:18
#4 0x3c2bc18 in void printField<unsigned int, &(amd_kernel_code_s::amd_kernel_code_version_major)>(llvm::StringRef, amd_kernel_code_s const&, llvm::raw_ostream&) /code/llvm-project/llvm/lib/Target/AMDGPU/Utils/AMDKernelCodeTUtils.cpp:78:23
#5 0x3c250ba in llvm::printAmdKernelCodeField(amd_kernel_code_s const&, int, llvm::raw_ostream&) /code/llvm-project/llvm/lib/Target/AMDGPU/Utils/AMDKernelCodeTUtils.cpp:104:5
#6 0x3c27ca3 in llvm::dumpAmdKernelCode(amd_kernel_code_s const*, llvm::raw_ostream&, char const*) /code/llvm-project/llvm/lib/Target/AMDGPU/Utils/AMDKernelCodeTUtils.cpp:113:5
#7 0x3a46e6c in llvm::AMDGPUTargetAsmStreamer::EmitAMDKernelCodeT(amd_kernel_code_s const&) /code/llvm-project/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp:161:3
#8 0xd371e4 in llvm::AMDGPUAsmPrinter::EmitFunctionBodyStart() /code/llvm-project/llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp:204:26
[...]
Uninitialized value was created by an allocation of 'KernelCode' in the stack frame of function '_ZN4llvm16AMDGPUAsmPrinter21EmitFunctionBodyStartEv'
#0 0xd36650 in llvm::AMDGPUAsmPrinter::EmitFunctionBodyStart() /code/llvm-project/llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp:192
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337079 91177308-0d34-0410-b5e6-96231b3b80d8
alexcrichton
pushed a commit
that referenced
this pull request
Aug 2, 2018
This reverts commit r337504 while I investigate a TSan bot failure that seems related: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/26526 #8 0x000055581f2895d8 (/b/sanitizer-x86_64-linux-autoconf/build/tsan_debug_build/bin/clang-7+0x1eb45d8) #9 0x000055581f294323 llvm::ConstantAggrKeyType<llvm::ConstantArray>::create(llvm::ArrayType*) const /b/sanitizer-x86_64-linux-autoconf/build/llvm/lib/IR/ConstantsContext.h:409:0 #10 0x000055581f294323 llvm::ConstantUniqueMap<llvm::ConstantArray>::create(llvm::ArrayType*, llvm::ConstantAggrKeyType<llvm::ConstantArray>, std::pair<unsigned int, std::pair<llvm::ArrayType*, llvm::ConstantAggrKeyType<llvm::ConstantArray> > >&) /b/sanitizer-x86_64-linux-autoconf/build/llvm/lib/IR/ConstantsContext.h:635:0 #11 0x000055581f294323 llvm::ConstantUniqueMap<llvm::ConstantArray>::getOrCreate(llvm::ArrayType*, llvm::ConstantAggrKeyType<llvm::ConstantArray>) /b/sanitizer-x86_64-linux-autoconf/build/llvm/lib/IR/ConstantsContext.h:654:0 #12 0x000055581f2944cb llvm::ConstantArray::get(llvm::ArrayType*, llvm::ArrayRef<llvm::Constant*>) /b/sanitizer-x86_64-linux-autoconf/build/llvm/lib/IR/Constants.cpp:964:0 #13 0x000055581fa27e19 llvm::SmallVectorBase::size() const /b/sanitizer-x86_64-linux-autoconf/build/llvm/include/llvm/ADT/SmallVector.h:53:0 #14 0x000055581fa27e19 llvm::SmallVectorImpl<llvm::Constant*>::resize(unsigned long) /b/sanitizer-x86_64-linux-autoconf/build/llvm/include/llvm/ADT/SmallVector.h:347:0 #15 0x000055581fa27e19 (anonymous namespace)::EmitArrayConstant(clang::CodeGen::CodeGenModule&, clang::ConstantArrayType const*, llvm::Type*, unsigned int, llvm::SmallVectorImpl<llvm::Constant*>&, llvm::Constant*) /b/sanitizer-x86_64-linux-autoconf/build/llvm/tools/clang/lib/CodeGen/CGExprConstant.cpp:669:0 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337511 91177308-0d34-0410-b5e6-96231b3b80d8
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Rust uses a lot of empty structs internally. That caused problems during SjLj preparation step as it expected that every function argument actually has some data in it which should be either copied/bitcasted.
This fix simply skips any action for arguments which have no data inside (structs with zero fields or arrays with zero elements)