I don't see any point in having both eh.selector.i32 and eh.selector.i64,
authorDuncan Sands <baldrick@free.fr>
Wed, 14 Oct 2009 16:11:37 +0000 (16:11 +0000)
committerDuncan Sands <baldrick@free.fr>
Wed, 14 Oct 2009 16:11:37 +0000 (16:11 +0000)
commitb01bbdcc1af27bd90b552bb1b62b48916e0d4be3
tree724ab8850796ff140c0c5381ceb40929197922a4
parent8db2cd1fc767086f65b5f93d9c7b4c1924774775
I don't see any point in having both eh.selector.i32 and eh.selector.i64,
so get rid of eh.selector.i64 and rename eh.selector.i32 to eh.selector.
Likewise for eh.typeid.for.  This aligns us with gcc, which always uses a
32 bit value for the selector on all platforms.  My understanding is that
the register allocator used to assert if the selector intrinsic size didn't
match the pointer size, and this was the reason for introducing the two
variants.  However my testing shows that this is no longer the case (I
fixed some bugs in selector lowering yesterday, and some more today in the
fastisel path; these might have caused the original problems).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84106 91177308-0d34-0410-b5e6-96231b3b80d8
docs/ExceptionHandling.html
include/llvm/IntrinsicInst.h
include/llvm/Intrinsics.td
lib/CodeGen/IntrinsicLowering.cpp
lib/CodeGen/SelectionDAG/FastISel.cpp
lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp
lib/CodeGen/SjLjEHPrepare.cpp
lib/VMCore/AutoUpgrade.cpp