Remove a hack that tries to understand incorrect triples from the

Triple class constructor.  Only valid triples should now be used
inside LLVM - front-ends are now responsable for rejecting or
correcting invalid target triples.  The Triple::normalize method
can be used to straighten out funky triples provided by users.
Give this a whirl through the buildbots to see if I caught all
places where triples enter LLVM.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112470 91177308-0d34-0410-b5e6-96231b3b80d8

docs/ReleaseNotes.html

@@ -347,6 +347,11 @@ expose new optimization opportunities:</p>
 <li>
   SMDiagnostic takes different parameters now. //FIXME: how to upgrade?
 </li>
+<li>
+  The constructor for the Triple class no longer tries to understand odd triple
+  specifications.  Frontends should ensure that they only pass valid triples to
+  LLVM.  The Triple::normalize utility method has been added to help front-ends
+  deal with funky triples.
 <li>
   Some APIs got renamed:
   <ul>

lib/Support/Triple.cpp

@@ -323,22 +323,6 @@ void Triple::Parse() const {
   Vendor = ParseVendor(getVendorName());
   OS = ParseOS(getOSName());
 
-  // Handle some exceptional cases where the OS / environment components are
-  // stuck into the vendor field.
-  // TODO: Remove this logic and have places that need it use 'normalize'.
-  if (StringRef(getTriple()).count('-') == 1) {
-    StringRef VendorName = getVendorName();
-
-    if (VendorName.startswith("mingw32")) { // 'i386-mingw32', etc.
-      Vendor = PC;
-      OS = MinGW32;
-      return;
-    }
-
-    // arm-elf is another example, but we don't currently parse anything about
-    // the environment.
-  }
-
   assert(isInitialized() && "Failed to initialize!");
 }