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
This commit is contained in:
Duncan Sands 2010-08-30 10:57:54 +00:00
parent cdd4f8c7cb
commit 12881e79b6
2 changed files with 5 additions and 16 deletions

View File

@ -347,6 +347,11 @@ expose new optimization opportunities:</p>
<li> <li>
SMDiagnostic takes different parameters now. //FIXME: how to upgrade? SMDiagnostic takes different parameters now. //FIXME: how to upgrade?
</li> </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> <li>
Some APIs got renamed: Some APIs got renamed:
<ul> <ul>

View File

@ -323,22 +323,6 @@ void Triple::Parse() const {
Vendor = ParseVendor(getVendorName()); Vendor = ParseVendor(getVendorName());
OS = ParseOS(getOSName()); 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!"); assert(isInitialized() && "Failed to initialize!");
} }