Split commit into two pieces, each more clearly NFCI

ping. With the other commits split out and landed, this is now much smaller at moving the isNonIntegralPointerType check into the correct place. This is still good to go from my perspective.

bump: this should be ready to review now.

bump? please review/merge this bugfix?

bump

Bump again? It's just a tiny bugfix that reames told me is needed (https://reviews.llvm.org/D59730?id=196652#inline-570528)

bump again? (I don't have commit rights.)

bump.

Friendly bump.

The added assertion will detect this:

[109/110] Running lit suite /data/vtjnash/julia/deps/srccache/llvm-svn/test/Transforms                                                                                       [19/519]
FAIL: LLVM :: Transforms/InstSimplify/vector_ptr_bitcast.ll (2527 of 4814)
******************** TEST 'LLVM :: Transforms/InstSimplify/vector_ptr_bitcast.ll' FAILED ********************
Script:
--
: 'RUN: at line 1';   /data/vtjnash/julia/deps/scratch/llvm-svn/build_Release+Asserts/bin/opt -S -instsimplify < /data/vtjnash/julia/deps/srccache/llvm-svn/test/Transforms/InstSimpl
ify/vector_ptr_bitcast.ll | /data/vtjnash/julia/deps/scratch/llvm-svn/build_Release+Asserts/bin/FileCheck /data/vtjnash/julia/deps/srccache/llvm-svn/test/Transforms/InstSimplify/vec
tor_ptr_bitcast.ll
--
Exit Code: 2

[GVN] teach ConstantFolding correct handling of non-integral addrspace casts

[GVN] teach ConstantFolding correct handling of non-integral addrspace casts

Bump. Fixed the other bug in handling vectors that you noted, and added an assert to catch that misuse.

FoldBitCast was being instructed to create invalid IR in several test cases. We happened to fold away them away before the verifier noticed, so this adds an explicit check, and corrects the caller FoldReinterpretLoadFromConstPtr to form valid IR when handling vectors of pointers with this method.

bump. please review, thanks!

@loladiro can you land this for me?

@loladiro bump. It sounds like this was approved, but it doesn't apply cleanly now.

Is this OK to land?

remove change that could result in a functional difference

Thanks @reames, I appreciate what you've already done here. I had started this a long time ago, where more of it was a functional change, then discovered you had recently already made most of the essential fixes and written the necessary tests. I've changed this into a stack of 3 commits that touch slightly different areas.

Split out part of the changes into two parent commits.

the warnings in that test are from a different, related bug. An approximate correction for that is:

diff --git a/lib/CodeGen/AsmPrinter/DIE.cpp b/lib/CodeGen/AsmPrinter/DIE.cpp
index a328851..73977f2 100644
--- a/lib/CodeGen/AsmPrinter/DIE.cpp
+++ b/lib/CodeGen/AsmPrinter/DIE.cpp
@@ -495,7 +495,8 @@ void DIELabel::EmitValue(const AsmPrinter *AP, dwarf::Form Form) const {
   AP->EmitLabelReference(Label, SizeOf(AP, Form),
                          Form == dwarf::DW_FORM_strp ||
                              Form == dwarf::DW_FORM_sec_offset ||
-                             Form == dwarf::DW_FORM_ref_addr);
+                             Form == dwarf::DW_FORM_ref_addr ||
+                             Form == dwarf::DW_FORM_data4);
 }

address review comments

This updates the ref_addr_relocation test to have better coverage of the various combinations of DWARF versions and architectures. Because the debug info framework in LLVM expects that .secrel32 .debug_info + offset exists (and LLVM also tests that the debug info isn't using labels that would be supported everywhere: "test that we don't create useless labels"), this also makes that a real relocation type and handles the printing and parsing of it.

bump

I couldn't get Keno's testcase to work for me (it shows the patch, but not the bug), so I re-extracted it with bugpoint and simplified it a bit more by hand.

I don't think the correct approach is to change the definition of this instruction to no longer implicitly define "CARRY". The correct approach would probably be for it to implicitly define both of the special registers that it sets (CARRY, CR0).

full context diff

it looks like the other disassembler targets also ignore Address and simply read the first N bytes from "Bytes", so i assume that was an intentional change in llvm3.5?

i don't know how to reduce the test case, but in the attached IR, the "loop-reduce" pass does an invalid transform for the computation of %57 from %25 from %"#s13.0"

@rnk I have updated the diff based on your comments (although I did not manage to locate a copy of clang-format). As suggested, I strengthened all of the conditional checks to assertions. The original code to retest the conditional was copied from the ARM code example and was not needed here.

reformat per comments