2010-01-01 10:31:22 +00:00
|
|
|
//===- X86DisassemblerTables.cpp - Disassembler tables ----------*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file is part of the X86 Disassembler Emitter.
|
|
|
|
// It contains the implementation of the disassembler tables.
|
|
|
|
// Documentation for the disassembler emitter in general can be found in
|
|
|
|
// X86DisasemblerEmitter.h.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "X86DisassemblerTables.h"
|
2013-04-08 18:41:23 +00:00
|
|
|
#include "X86DisassemblerShared.h"
|
2011-05-02 19:34:44 +00:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2010-01-01 10:31:22 +00:00
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
|
|
|
#include "llvm/Support/Format.h"
|
2013-04-08 18:41:23 +00:00
|
|
|
#include "llvm/TableGen/TableGenBackend.h"
|
2012-08-15 19:34:23 +00:00
|
|
|
#include <map>
|
2010-01-01 10:31:22 +00:00
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
using namespace X86Disassembler;
|
2012-08-15 19:34:23 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
/// inheritsFrom - Indicates whether all instructions in one class also belong
|
|
|
|
/// to another class.
|
|
|
|
///
|
|
|
|
/// @param child - The class that may be the subset
|
|
|
|
/// @param parent - The class that may be the superset
|
|
|
|
/// @return - True if child is a subset of parent, false otherwise.
|
|
|
|
static inline bool inheritsFrom(InstructionContext child,
|
2011-10-20 21:10:27 +00:00
|
|
|
InstructionContext parent,
|
|
|
|
bool VEX_LIG = false) {
|
2010-01-01 10:31:22 +00:00
|
|
|
if (child == parent)
|
|
|
|
return true;
|
2012-08-15 19:34:23 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
switch (parent) {
|
|
|
|
case IC:
|
2011-10-20 21:10:27 +00:00
|
|
|
return(inheritsFrom(child, IC_64BIT) ||
|
|
|
|
inheritsFrom(child, IC_OPSIZE) ||
|
2012-04-14 13:54:10 +00:00
|
|
|
inheritsFrom(child, IC_ADSIZE) ||
|
2011-10-20 21:10:27 +00:00
|
|
|
inheritsFrom(child, IC_XD) ||
|
|
|
|
inheritsFrom(child, IC_XS));
|
2010-01-01 10:31:22 +00:00
|
|
|
case IC_64BIT:
|
|
|
|
return(inheritsFrom(child, IC_64BIT_REXW) ||
|
|
|
|
inheritsFrom(child, IC_64BIT_OPSIZE) ||
|
2012-04-14 13:54:10 +00:00
|
|
|
inheritsFrom(child, IC_64BIT_ADSIZE) ||
|
2010-01-01 10:31:22 +00:00
|
|
|
inheritsFrom(child, IC_64BIT_XD) ||
|
|
|
|
inheritsFrom(child, IC_64BIT_XS));
|
|
|
|
case IC_OPSIZE:
|
2011-10-20 21:10:27 +00:00
|
|
|
return inheritsFrom(child, IC_64BIT_OPSIZE);
|
2012-04-14 13:54:10 +00:00
|
|
|
case IC_ADSIZE:
|
|
|
|
case IC_64BIT_ADSIZE:
|
|
|
|
return false;
|
2010-01-01 10:31:22 +00:00
|
|
|
case IC_XD:
|
2011-10-20 21:10:27 +00:00
|
|
|
return inheritsFrom(child, IC_64BIT_XD);
|
2010-01-01 10:31:22 +00:00
|
|
|
case IC_XS:
|
2011-10-20 21:10:27 +00:00
|
|
|
return inheritsFrom(child, IC_64BIT_XS);
|
|
|
|
case IC_XD_OPSIZE:
|
|
|
|
return inheritsFrom(child, IC_64BIT_XD_OPSIZE);
|
|
|
|
case IC_XS_OPSIZE:
|
|
|
|
return inheritsFrom(child, IC_64BIT_XS_OPSIZE);
|
2010-01-01 10:31:22 +00:00
|
|
|
case IC_64BIT_REXW:
|
|
|
|
return(inheritsFrom(child, IC_64BIT_REXW_XS) ||
|
|
|
|
inheritsFrom(child, IC_64BIT_REXW_XD) ||
|
|
|
|
inheritsFrom(child, IC_64BIT_REXW_OPSIZE));
|
|
|
|
case IC_64BIT_OPSIZE:
|
|
|
|
return(inheritsFrom(child, IC_64BIT_REXW_OPSIZE));
|
|
|
|
case IC_64BIT_XD:
|
|
|
|
return(inheritsFrom(child, IC_64BIT_REXW_XD));
|
|
|
|
case IC_64BIT_XS:
|
|
|
|
return(inheritsFrom(child, IC_64BIT_REXW_XS));
|
2011-10-20 21:10:27 +00:00
|
|
|
case IC_64BIT_XD_OPSIZE:
|
|
|
|
case IC_64BIT_XS_OPSIZE:
|
2010-01-01 10:31:22 +00:00
|
|
|
return false;
|
2011-10-20 21:10:27 +00:00
|
|
|
case IC_64BIT_REXW_XD:
|
2010-01-01 10:31:22 +00:00
|
|
|
case IC_64BIT_REXW_XS:
|
|
|
|
case IC_64BIT_REXW_OPSIZE:
|
|
|
|
return false;
|
2011-05-02 19:34:44 +00:00
|
|
|
case IC_VEX:
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
return (VEX_LIG && inheritsFrom(child, IC_VEX_L_W)) ||
|
|
|
|
inheritsFrom(child, IC_VEX_W) ||
|
2011-10-20 21:10:27 +00:00
|
|
|
(VEX_LIG && inheritsFrom(child, IC_VEX_L));
|
2011-05-02 19:34:44 +00:00
|
|
|
case IC_VEX_XS:
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
return (VEX_LIG && inheritsFrom(child, IC_VEX_L_W_XS)) ||
|
|
|
|
inheritsFrom(child, IC_VEX_W_XS) ||
|
2011-10-20 21:10:27 +00:00
|
|
|
(VEX_LIG && inheritsFrom(child, IC_VEX_L_XS));
|
2011-05-02 19:34:44 +00:00
|
|
|
case IC_VEX_XD:
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
return (VEX_LIG && inheritsFrom(child, IC_VEX_L_W_XD)) ||
|
|
|
|
inheritsFrom(child, IC_VEX_W_XD) ||
|
2011-10-20 21:10:27 +00:00
|
|
|
(VEX_LIG && inheritsFrom(child, IC_VEX_L_XD));
|
|
|
|
case IC_VEX_OPSIZE:
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
return (VEX_LIG && inheritsFrom(child, IC_VEX_L_W_OPSIZE)) ||
|
|
|
|
inheritsFrom(child, IC_VEX_W_OPSIZE) ||
|
2011-10-20 21:10:27 +00:00
|
|
|
(VEX_LIG && inheritsFrom(child, IC_VEX_L_OPSIZE));
|
2011-05-02 19:34:44 +00:00
|
|
|
case IC_VEX_W:
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
return VEX_LIG && inheritsFrom(child, IC_VEX_L_W);
|
2011-05-02 19:34:44 +00:00
|
|
|
case IC_VEX_W_XS:
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
return VEX_LIG && inheritsFrom(child, IC_VEX_L_W_XS);
|
2011-05-02 19:34:44 +00:00
|
|
|
case IC_VEX_W_XD:
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
return VEX_LIG && inheritsFrom(child, IC_VEX_L_W_XD);
|
2011-10-20 21:10:27 +00:00
|
|
|
case IC_VEX_W_OPSIZE:
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
return VEX_LIG && inheritsFrom(child, IC_VEX_L_W_OPSIZE);
|
2011-10-20 21:10:27 +00:00
|
|
|
case IC_VEX_L:
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
return inheritsFrom(child, IC_VEX_L_W);
|
2011-10-20 21:10:27 +00:00
|
|
|
case IC_VEX_L_XS:
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
return inheritsFrom(child, IC_VEX_L_W_XS);
|
2011-10-20 21:10:27 +00:00
|
|
|
case IC_VEX_L_XD:
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
return inheritsFrom(child, IC_VEX_L_W_XD);
|
2011-10-20 21:10:27 +00:00
|
|
|
case IC_VEX_L_OPSIZE:
|
2012-04-14 13:54:10 +00:00
|
|
|
return inheritsFrom(child, IC_VEX_L_W_OPSIZE);
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
case IC_VEX_L_W:
|
|
|
|
case IC_VEX_L_W_XS:
|
|
|
|
case IC_VEX_L_W_XD:
|
2012-04-14 13:54:10 +00:00
|
|
|
case IC_VEX_L_W_OPSIZE:
|
2011-05-02 19:34:44 +00:00
|
|
|
return false;
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
case IC_EVEX:
|
|
|
|
return inheritsFrom(child, IC_EVEX_W) ||
|
|
|
|
inheritsFrom(child, IC_EVEX_L_W);
|
|
|
|
case IC_EVEX_XS:
|
|
|
|
return inheritsFrom(child, IC_EVEX_W_XS) ||
|
|
|
|
inheritsFrom(child, IC_EVEX_L_W_XS);
|
|
|
|
case IC_EVEX_XD:
|
|
|
|
return inheritsFrom(child, IC_EVEX_W_XD) ||
|
|
|
|
inheritsFrom(child, IC_EVEX_L_W_XD);
|
|
|
|
case IC_EVEX_OPSIZE:
|
|
|
|
return inheritsFrom(child, IC_EVEX_W_OPSIZE) ||
|
|
|
|
inheritsFrom(child, IC_EVEX_L_W_OPSIZE);
|
|
|
|
case IC_EVEX_W:
|
|
|
|
case IC_EVEX_W_XS:
|
|
|
|
case IC_EVEX_W_XD:
|
|
|
|
case IC_EVEX_W_OPSIZE:
|
|
|
|
return false;
|
|
|
|
case IC_EVEX_L:
|
|
|
|
case IC_EVEX_L_XS:
|
|
|
|
case IC_EVEX_L_XD:
|
|
|
|
case IC_EVEX_L_OPSIZE:
|
|
|
|
return false;
|
|
|
|
case IC_EVEX_L_W:
|
|
|
|
case IC_EVEX_L_W_XS:
|
|
|
|
case IC_EVEX_L_W_XD:
|
|
|
|
case IC_EVEX_L_W_OPSIZE:
|
|
|
|
return false;
|
|
|
|
case IC_EVEX_L2:
|
|
|
|
case IC_EVEX_L2_XS:
|
|
|
|
case IC_EVEX_L2_XD:
|
|
|
|
case IC_EVEX_L2_OPSIZE:
|
|
|
|
return false;
|
|
|
|
case IC_EVEX_L2_W:
|
|
|
|
case IC_EVEX_L2_W_XS:
|
|
|
|
case IC_EVEX_L2_W_XD:
|
|
|
|
case IC_EVEX_L2_W_OPSIZE:
|
|
|
|
return false;
|
|
|
|
case IC_EVEX_K:
|
|
|
|
return inheritsFrom(child, IC_EVEX_W_K) ||
|
|
|
|
inheritsFrom(child, IC_EVEX_L_W_K);
|
|
|
|
case IC_EVEX_XS_K:
|
|
|
|
return inheritsFrom(child, IC_EVEX_W_XS_K) ||
|
|
|
|
inheritsFrom(child, IC_EVEX_L_W_XS_K);
|
|
|
|
case IC_EVEX_XD_K:
|
|
|
|
return inheritsFrom(child, IC_EVEX_W_XD_K) ||
|
|
|
|
inheritsFrom(child, IC_EVEX_L_W_XD_K);
|
|
|
|
case IC_EVEX_OPSIZE_K:
|
|
|
|
return inheritsFrom(child, IC_EVEX_W_OPSIZE_K) ||
|
|
|
|
inheritsFrom(child, IC_EVEX_W_OPSIZE_K);
|
|
|
|
case IC_EVEX_W_K:
|
|
|
|
case IC_EVEX_W_XS_K:
|
|
|
|
case IC_EVEX_W_XD_K:
|
|
|
|
case IC_EVEX_W_OPSIZE_K:
|
|
|
|
return false;
|
|
|
|
case IC_EVEX_L_K:
|
|
|
|
case IC_EVEX_L_XS_K:
|
|
|
|
case IC_EVEX_L_XD_K:
|
|
|
|
case IC_EVEX_L_OPSIZE_K:
|
|
|
|
return false;
|
|
|
|
case IC_EVEX_W_KZ:
|
|
|
|
case IC_EVEX_W_XS_KZ:
|
|
|
|
case IC_EVEX_W_XD_KZ:
|
|
|
|
case IC_EVEX_W_OPSIZE_KZ:
|
|
|
|
return false;
|
|
|
|
case IC_EVEX_L_KZ:
|
|
|
|
case IC_EVEX_L_XS_KZ:
|
|
|
|
case IC_EVEX_L_XD_KZ:
|
|
|
|
case IC_EVEX_L_OPSIZE_KZ:
|
|
|
|
return false;
|
|
|
|
case IC_EVEX_L_W_K:
|
|
|
|
case IC_EVEX_L_W_XS_K:
|
|
|
|
case IC_EVEX_L_W_XD_K:
|
|
|
|
case IC_EVEX_L_W_OPSIZE_K:
|
|
|
|
case IC_EVEX_L_W_KZ:
|
|
|
|
case IC_EVEX_L_W_XS_KZ:
|
|
|
|
case IC_EVEX_L_W_XD_KZ:
|
|
|
|
case IC_EVEX_L_W_OPSIZE_KZ:
|
|
|
|
return false;
|
|
|
|
case IC_EVEX_L2_K:
|
|
|
|
case IC_EVEX_L2_B:
|
|
|
|
case IC_EVEX_L2_XS_K:
|
|
|
|
case IC_EVEX_L2_XD_K:
|
|
|
|
case IC_EVEX_L2_OPSIZE_K:
|
|
|
|
case IC_EVEX_L2_OPSIZE_B:
|
|
|
|
case IC_EVEX_L2_OPSIZE_K_B:
|
|
|
|
case IC_EVEX_L2_KZ:
|
|
|
|
case IC_EVEX_L2_XS_KZ:
|
|
|
|
case IC_EVEX_L2_XD_KZ:
|
|
|
|
case IC_EVEX_L2_OPSIZE_KZ:
|
|
|
|
case IC_EVEX_L2_OPSIZE_KZ_B:
|
|
|
|
return false;
|
|
|
|
case IC_EVEX_L2_W_K:
|
|
|
|
case IC_EVEX_L2_W_B:
|
|
|
|
case IC_EVEX_L2_W_XS_K:
|
|
|
|
case IC_EVEX_L2_W_XD_K:
|
|
|
|
case IC_EVEX_L2_W_OPSIZE_K:
|
|
|
|
case IC_EVEX_L2_W_OPSIZE_B:
|
|
|
|
case IC_EVEX_L2_W_OPSIZE_K_B:
|
|
|
|
case IC_EVEX_L2_W_KZ:
|
|
|
|
case IC_EVEX_L2_W_XS_KZ:
|
|
|
|
case IC_EVEX_L2_W_XD_KZ:
|
|
|
|
case IC_EVEX_L2_W_OPSIZE_KZ:
|
|
|
|
case IC_EVEX_L2_W_OPSIZE_KZ_B:
|
|
|
|
return false;
|
2010-01-01 10:31:22 +00:00
|
|
|
default:
|
2011-10-20 21:10:27 +00:00
|
|
|
llvm_unreachable("Unknown instruction class");
|
2010-01-01 10:31:22 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// outranks - Indicates whether, if an instruction has two different applicable
|
|
|
|
/// classes, which class should be preferred when performing decode. This
|
|
|
|
/// imposes a total ordering (ties are resolved toward "lower")
|
|
|
|
///
|
|
|
|
/// @param upper - The class that may be preferable
|
|
|
|
/// @param lower - The class that may be less preferable
|
|
|
|
/// @return - True if upper is to be preferred, false otherwise.
|
2012-08-15 19:34:23 +00:00
|
|
|
static inline bool outranks(InstructionContext upper,
|
2010-01-01 10:31:22 +00:00
|
|
|
InstructionContext lower) {
|
|
|
|
assert(upper < IC_max);
|
|
|
|
assert(lower < IC_max);
|
2012-08-15 19:34:23 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
#define ENUM_ENTRY(n, r, d) r,
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
#define ENUM_ENTRY_K_B(n, r, d) ENUM_ENTRY(n, r, d) \
|
|
|
|
ENUM_ENTRY(n##_K_B, r, d) ENUM_ENTRY(n##_KZ_B, r, d) \
|
|
|
|
ENUM_ENTRY(n##_KZ, r, d) ENUM_ENTRY(n##_K, r, d) ENUM_ENTRY(n##_B, r, d)
|
2010-01-01 10:31:22 +00:00
|
|
|
static int ranks[IC_max] = {
|
|
|
|
INSTRUCTION_CONTEXTS
|
|
|
|
};
|
|
|
|
#undef ENUM_ENTRY
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
#undef ENUM_ENTRY_K_B
|
2012-08-15 19:34:23 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
return (ranks[upper] > ranks[lower]);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// stringForContext - Returns a string containing the name of a particular
|
|
|
|
/// InstructionContext, usually for diagnostic purposes.
|
|
|
|
///
|
|
|
|
/// @param insnContext - The instruction class to transform to a string.
|
|
|
|
/// @return - A statically-allocated string constant that contains the
|
|
|
|
/// name of the instruction class.
|
|
|
|
static inline const char* stringForContext(InstructionContext insnContext) {
|
|
|
|
switch (insnContext) {
|
|
|
|
default:
|
|
|
|
llvm_unreachable("Unhandled instruction class");
|
|
|
|
#define ENUM_ENTRY(n, r, d) case n: return #n; break;
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
#define ENUM_ENTRY_K_B(n, r, d) ENUM_ENTRY(n, r, d) ENUM_ENTRY(n##_K_B, r, d)\
|
|
|
|
ENUM_ENTRY(n##_KZ, r, d) ENUM_ENTRY(n##_K, r, d) ENUM_ENTRY(n##_B, r, d)\
|
|
|
|
ENUM_ENTRY(n##_KZ_B, r, d)
|
2010-01-01 10:31:22 +00:00
|
|
|
INSTRUCTION_CONTEXTS
|
|
|
|
#undef ENUM_ENTRY
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
#undef ENUM_ENTRY_K_B
|
2010-01-01 10:31:22 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// stringForOperandType - Like stringForContext, but for OperandTypes.
|
|
|
|
static inline const char* stringForOperandType(OperandType type) {
|
|
|
|
switch (type) {
|
|
|
|
default:
|
|
|
|
llvm_unreachable("Unhandled type");
|
|
|
|
#define ENUM_ENTRY(i, d) case i: return #i;
|
|
|
|
TYPES
|
|
|
|
#undef ENUM_ENTRY
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// stringForOperandEncoding - like stringForContext, but for
|
|
|
|
/// OperandEncodings.
|
|
|
|
static inline const char* stringForOperandEncoding(OperandEncoding encoding) {
|
|
|
|
switch (encoding) {
|
|
|
|
default:
|
|
|
|
llvm_unreachable("Unhandled encoding");
|
|
|
|
#define ENUM_ENTRY(i, d) case i: return #i;
|
|
|
|
ENCODINGS
|
|
|
|
#undef ENUM_ENTRY
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// getDecisionType - Determines whether a ModRM decision with 255 entries can
|
|
|
|
/// be compacted by eliminating redundant information.
|
|
|
|
///
|
|
|
|
/// @param decision - The decision to be compacted.
|
|
|
|
/// @return - The compactest available representation for the decision.
|
2012-08-15 19:34:23 +00:00
|
|
|
static ModRMDecisionType getDecisionType(ModRMDecision &decision) {
|
2010-01-01 10:31:22 +00:00
|
|
|
bool satisfiesOneEntry = true;
|
|
|
|
bool satisfiesSplitRM = true;
|
2012-04-14 13:54:10 +00:00
|
|
|
bool satisfiesSplitReg = true;
|
2012-12-02 13:10:19 +00:00
|
|
|
bool satisfiesSplitMisc = true;
|
2012-04-14 13:54:10 +00:00
|
|
|
|
2012-08-15 19:34:23 +00:00
|
|
|
for (unsigned index = 0; index < 256; ++index) {
|
2010-01-01 10:31:22 +00:00
|
|
|
if (decision.instructionIDs[index] != decision.instructionIDs[0])
|
|
|
|
satisfiesOneEntry = false;
|
2012-04-14 13:54:10 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
if (((index & 0xc0) == 0xc0) &&
|
|
|
|
(decision.instructionIDs[index] != decision.instructionIDs[0xc0]))
|
|
|
|
satisfiesSplitRM = false;
|
2012-04-14 13:54:10 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
if (((index & 0xc0) != 0xc0) &&
|
|
|
|
(decision.instructionIDs[index] != decision.instructionIDs[0x00]))
|
|
|
|
satisfiesSplitRM = false;
|
2012-04-14 13:54:10 +00:00
|
|
|
|
|
|
|
if (((index & 0xc0) == 0xc0) &&
|
|
|
|
(decision.instructionIDs[index] != decision.instructionIDs[index&0xf8]))
|
|
|
|
satisfiesSplitReg = false;
|
|
|
|
|
|
|
|
if (((index & 0xc0) != 0xc0) &&
|
|
|
|
(decision.instructionIDs[index] != decision.instructionIDs[index&0x38]))
|
2012-12-02 13:10:19 +00:00
|
|
|
satisfiesSplitMisc = false;
|
2010-01-01 10:31:22 +00:00
|
|
|
}
|
2012-04-14 13:54:10 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
if (satisfiesOneEntry)
|
|
|
|
return MODRM_ONEENTRY;
|
2012-04-14 13:54:10 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
if (satisfiesSplitRM)
|
|
|
|
return MODRM_SPLITRM;
|
2012-04-14 13:54:10 +00:00
|
|
|
|
2012-12-02 13:10:19 +00:00
|
|
|
if (satisfiesSplitReg && satisfiesSplitMisc)
|
2012-04-14 13:54:10 +00:00
|
|
|
return MODRM_SPLITREG;
|
|
|
|
|
2012-12-02 13:10:19 +00:00
|
|
|
if (satisfiesSplitMisc)
|
|
|
|
return MODRM_SPLITMISC;
|
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
return MODRM_FULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// stringForDecisionType - Returns a statically-allocated string corresponding
|
|
|
|
/// to a particular decision type.
|
|
|
|
///
|
|
|
|
/// @param dt - The decision type.
|
2012-08-15 19:34:23 +00:00
|
|
|
/// @return - A pointer to the statically-allocated string (e.g.,
|
2010-01-01 10:31:22 +00:00
|
|
|
/// "MODRM_ONEENTRY" for MODRM_ONEENTRY).
|
2012-08-15 19:34:23 +00:00
|
|
|
static const char* stringForDecisionType(ModRMDecisionType dt) {
|
2010-01-01 10:31:22 +00:00
|
|
|
#define ENUM_ENTRY(n) case n: return #n;
|
|
|
|
switch (dt) {
|
|
|
|
default:
|
2012-08-15 19:34:23 +00:00
|
|
|
llvm_unreachable("Unknown decision type");
|
2010-01-01 10:31:22 +00:00
|
|
|
MODRMTYPES
|
2012-08-15 19:34:23 +00:00
|
|
|
};
|
2010-01-01 10:31:22 +00:00
|
|
|
#undef ENUM_ENTRY
|
|
|
|
}
|
2012-08-15 19:34:23 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
/// stringForModifierType - Returns a statically-allocated string corresponding
|
|
|
|
/// to an opcode modifier type.
|
|
|
|
///
|
|
|
|
/// @param mt - The modifier type.
|
|
|
|
/// @return - A pointer to the statically-allocated string (e.g.,
|
|
|
|
/// "MODIFIER_NONE" for MODIFIER_NONE).
|
2012-08-15 19:34:23 +00:00
|
|
|
static const char* stringForModifierType(ModifierType mt) {
|
2010-01-01 10:31:22 +00:00
|
|
|
#define ENUM_ENTRY(n) case n: return #n;
|
|
|
|
switch(mt) {
|
|
|
|
default:
|
|
|
|
llvm_unreachable("Unknown modifier type");
|
|
|
|
MODIFIER_TYPES
|
|
|
|
};
|
|
|
|
#undef ENUM_ENTRY
|
|
|
|
}
|
2012-08-15 19:34:23 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
DisassemblerTables::DisassemblerTables() {
|
|
|
|
unsigned i;
|
2012-08-15 19:34:23 +00:00
|
|
|
|
2011-05-02 19:34:44 +00:00
|
|
|
for (i = 0; i < array_lengthof(Tables); i++) {
|
2010-01-01 10:31:22 +00:00
|
|
|
Tables[i] = new ContextDecision;
|
|
|
|
memset(Tables[i], 0, sizeof(ContextDecision));
|
|
|
|
}
|
2012-08-15 19:34:23 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
HasConflicts = false;
|
|
|
|
}
|
2012-08-15 19:34:23 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
DisassemblerTables::~DisassemblerTables() {
|
|
|
|
unsigned i;
|
2012-08-15 19:34:23 +00:00
|
|
|
|
2011-05-02 19:34:44 +00:00
|
|
|
for (i = 0; i < array_lengthof(Tables); i++)
|
2010-01-01 10:31:22 +00:00
|
|
|
delete Tables[i];
|
|
|
|
}
|
2012-08-15 19:34:23 +00:00
|
|
|
|
|
|
|
void DisassemblerTables::emitModRMDecision(raw_ostream &o1, raw_ostream &o2,
|
|
|
|
unsigned &i1, unsigned &i2,
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
unsigned &ModRMTableNum,
|
2012-08-15 19:34:23 +00:00
|
|
|
ModRMDecision &decision) const {
|
|
|
|
static uint32_t sTableNumber = 0;
|
|
|
|
static uint32_t sEntryNumber = 1;
|
2010-01-01 10:31:22 +00:00
|
|
|
ModRMDecisionType dt = getDecisionType(decision);
|
2012-04-14 13:54:10 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
if (dt == MODRM_ONEENTRY && decision.instructionIDs[0] == 0)
|
|
|
|
{
|
|
|
|
o2.indent(i2) << "{ /* ModRMDecision */" << "\n";
|
|
|
|
i2++;
|
2012-04-14 13:54:10 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
o2.indent(i2) << stringForDecisionType(dt) << "," << "\n";
|
2012-04-14 13:54:10 +00:00
|
|
|
o2.indent(i2) << 0 << " /* EmptyTable */\n";
|
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
i2--;
|
|
|
|
o2.indent(i2) << "}";
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
std::vector<unsigned> ModRMDecision;
|
2012-04-14 13:54:10 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
switch (dt) {
|
|
|
|
default:
|
|
|
|
llvm_unreachable("Unknown decision type");
|
|
|
|
case MODRM_ONEENTRY:
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
ModRMDecision.push_back(decision.instructionIDs[0]);
|
2010-01-01 10:31:22 +00:00
|
|
|
break;
|
|
|
|
case MODRM_SPLITRM:
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
ModRMDecision.push_back(decision.instructionIDs[0x00]);
|
|
|
|
ModRMDecision.push_back(decision.instructionIDs[0xc0]);
|
2012-04-14 13:54:10 +00:00
|
|
|
break;
|
|
|
|
case MODRM_SPLITREG:
|
2012-08-15 19:34:23 +00:00
|
|
|
for (unsigned index = 0; index < 64; index += 8)
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
ModRMDecision.push_back(decision.instructionIDs[index]);
|
2012-08-15 19:34:23 +00:00
|
|
|
for (unsigned index = 0xc0; index < 256; index += 8)
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
ModRMDecision.push_back(decision.instructionIDs[index]);
|
2010-01-01 10:31:22 +00:00
|
|
|
break;
|
2012-12-02 13:10:19 +00:00
|
|
|
case MODRM_SPLITMISC:
|
|
|
|
for (unsigned index = 0; index < 64; index += 8)
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
ModRMDecision.push_back(decision.instructionIDs[index]);
|
2012-12-02 13:10:19 +00:00
|
|
|
for (unsigned index = 0xc0; index < 256; ++index)
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
ModRMDecision.push_back(decision.instructionIDs[index]);
|
2012-12-02 13:10:19 +00:00
|
|
|
break;
|
2010-01-01 10:31:22 +00:00
|
|
|
case MODRM_FULL:
|
2012-08-15 19:34:23 +00:00
|
|
|
for (unsigned index = 0; index < 256; ++index)
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
ModRMDecision.push_back(decision.instructionIDs[index]);
|
2010-01-01 10:31:22 +00:00
|
|
|
break;
|
|
|
|
}
|
2012-04-14 13:54:10 +00:00
|
|
|
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
unsigned &EntryNumber = ModRMTable[ModRMDecision];
|
|
|
|
if (EntryNumber == 0) {
|
|
|
|
EntryNumber = ModRMTableNum;
|
|
|
|
|
|
|
|
ModRMTableNum += ModRMDecision.size();
|
|
|
|
o1 << "/* Table" << EntryNumber << " */\n";
|
|
|
|
i1++;
|
|
|
|
for (std::vector<unsigned>::const_iterator I = ModRMDecision.begin(),
|
|
|
|
E = ModRMDecision.end(); I != E; ++I) {
|
|
|
|
o1.indent(i1 * 2) << format("0x%hx", *I) << ", /* "
|
|
|
|
<< InstructionSpecifiers[*I].name << " */\n";
|
|
|
|
}
|
|
|
|
i1--;
|
|
|
|
}
|
2012-04-14 13:54:10 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
o2.indent(i2) << "{ /* struct ModRMDecision */" << "\n";
|
|
|
|
i2++;
|
2012-04-14 13:54:10 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
o2.indent(i2) << stringForDecisionType(dt) << "," << "\n";
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
o2.indent(i2) << EntryNumber << " /* Table" << EntryNumber << " */\n";
|
2012-04-14 13:54:10 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
i2--;
|
|
|
|
o2.indent(i2) << "}";
|
2012-04-14 13:54:10 +00:00
|
|
|
|
|
|
|
switch (dt) {
|
|
|
|
default:
|
|
|
|
llvm_unreachable("Unknown decision type");
|
|
|
|
case MODRM_ONEENTRY:
|
|
|
|
sEntryNumber += 1;
|
|
|
|
break;
|
|
|
|
case MODRM_SPLITRM:
|
|
|
|
sEntryNumber += 2;
|
|
|
|
break;
|
|
|
|
case MODRM_SPLITREG:
|
|
|
|
sEntryNumber += 16;
|
|
|
|
break;
|
2012-12-02 13:10:19 +00:00
|
|
|
case MODRM_SPLITMISC:
|
|
|
|
sEntryNumber += 8 + 64;
|
|
|
|
break;
|
2012-04-14 13:54:10 +00:00
|
|
|
case MODRM_FULL:
|
|
|
|
sEntryNumber += 256;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2012-12-02 13:10:19 +00:00
|
|
|
// We assume that the index can fit into uint16_t.
|
|
|
|
assert(sEntryNumber < 65536U &&
|
|
|
|
"Index into ModRMDecision is too large for uint16_t!");
|
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
++sTableNumber;
|
|
|
|
}
|
|
|
|
|
2012-08-15 19:34:23 +00:00
|
|
|
void DisassemblerTables::emitOpcodeDecision(raw_ostream &o1, raw_ostream &o2,
|
|
|
|
unsigned &i1, unsigned &i2,
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
unsigned &ModRMTableNum,
|
2012-08-15 19:34:23 +00:00
|
|
|
OpcodeDecision &decision) const {
|
2010-01-01 10:31:22 +00:00
|
|
|
o2.indent(i2) << "{ /* struct OpcodeDecision */" << "\n";
|
|
|
|
i2++;
|
|
|
|
o2.indent(i2) << "{" << "\n";
|
|
|
|
i2++;
|
|
|
|
|
2012-08-15 19:34:23 +00:00
|
|
|
for (unsigned index = 0; index < 256; ++index) {
|
2010-01-01 10:31:22 +00:00
|
|
|
o2.indent(i2);
|
|
|
|
|
|
|
|
o2 << "/* 0x" << format("%02hhx", index) << " */" << "\n";
|
|
|
|
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
emitModRMDecision(o1, o2, i1, i2, ModRMTableNum,
|
|
|
|
decision.modRMDecisions[index]);
|
2010-01-01 10:31:22 +00:00
|
|
|
|
|
|
|
if (index < 255)
|
|
|
|
o2 << ",";
|
|
|
|
|
|
|
|
o2 << "\n";
|
|
|
|
}
|
|
|
|
|
|
|
|
i2--;
|
|
|
|
o2.indent(i2) << "}" << "\n";
|
|
|
|
i2--;
|
|
|
|
o2.indent(i2) << "}" << "\n";
|
|
|
|
}
|
|
|
|
|
2012-08-15 19:34:23 +00:00
|
|
|
void DisassemblerTables::emitContextDecision(raw_ostream &o1, raw_ostream &o2,
|
|
|
|
unsigned &i1, unsigned &i2,
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
unsigned &ModRMTableNum,
|
2012-08-15 19:34:23 +00:00
|
|
|
ContextDecision &decision,
|
|
|
|
const char* name) const {
|
2011-02-20 12:57:14 +00:00
|
|
|
o2.indent(i2) << "static const struct ContextDecision " << name << " = {\n";
|
2010-01-01 10:31:22 +00:00
|
|
|
i2++;
|
|
|
|
o2.indent(i2) << "{ /* opcodeDecisions */" << "\n";
|
|
|
|
i2++;
|
|
|
|
|
2012-08-15 19:34:23 +00:00
|
|
|
for (unsigned index = 0; index < IC_max; ++index) {
|
2010-01-01 10:31:22 +00:00
|
|
|
o2.indent(i2) << "/* ";
|
|
|
|
o2 << stringForContext((InstructionContext)index);
|
|
|
|
o2 << " */";
|
|
|
|
o2 << "\n";
|
|
|
|
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
emitOpcodeDecision(o1, o2, i1, i2, ModRMTableNum,
|
|
|
|
decision.opcodeDecisions[index]);
|
2010-01-01 10:31:22 +00:00
|
|
|
|
|
|
|
if (index + 1 < IC_max)
|
|
|
|
o2 << ", ";
|
|
|
|
}
|
|
|
|
|
|
|
|
i2--;
|
|
|
|
o2.indent(i2) << "}" << "\n";
|
|
|
|
i2--;
|
|
|
|
o2.indent(i2) << "};" << "\n";
|
|
|
|
}
|
|
|
|
|
2012-08-15 19:34:23 +00:00
|
|
|
void DisassemblerTables::emitInstructionInfo(raw_ostream &o,
|
|
|
|
unsigned &i) const {
|
|
|
|
unsigned NumInstructions = InstructionSpecifiers.size();
|
|
|
|
|
|
|
|
o << "static const struct OperandSpecifier x86OperandSets[]["
|
|
|
|
<< X86_MAX_OPERANDS << "] = {\n";
|
|
|
|
|
|
|
|
typedef std::vector<std::pair<const char *, const char *> > OperandListTy;
|
|
|
|
std::map<OperandListTy, unsigned> OperandSets;
|
|
|
|
|
|
|
|
unsigned OperandSetNum = 0;
|
|
|
|
for (unsigned Index = 0; Index < NumInstructions; ++Index) {
|
|
|
|
OperandListTy OperandList;
|
|
|
|
|
|
|
|
for (unsigned OperandIndex = 0; OperandIndex < X86_MAX_OPERANDS;
|
|
|
|
++OperandIndex) {
|
|
|
|
const char *Encoding =
|
|
|
|
stringForOperandEncoding((OperandEncoding)InstructionSpecifiers[Index]
|
|
|
|
.operands[OperandIndex].encoding);
|
|
|
|
const char *Type =
|
|
|
|
stringForOperandType((OperandType)InstructionSpecifiers[Index]
|
|
|
|
.operands[OperandIndex].type);
|
|
|
|
OperandList.push_back(std::make_pair(Encoding, Type));
|
|
|
|
}
|
|
|
|
unsigned &N = OperandSets[OperandList];
|
|
|
|
if (N != 0) continue;
|
|
|
|
|
|
|
|
N = ++OperandSetNum;
|
|
|
|
|
|
|
|
o << " { /* " << (OperandSetNum - 1) << " */\n";
|
|
|
|
for (unsigned i = 0, e = OperandList.size(); i != e; ++i) {
|
|
|
|
o << " { " << OperandList[i].first << ", "
|
|
|
|
<< OperandList[i].second << " },\n";
|
|
|
|
}
|
|
|
|
o << " },\n";
|
|
|
|
}
|
|
|
|
o << "};" << "\n\n";
|
|
|
|
|
2011-02-20 12:57:14 +00:00
|
|
|
o.indent(i * 2) << "static const struct InstructionSpecifier ";
|
|
|
|
o << INSTRUCTIONS_STR "[" << InstructionSpecifiers.size() << "] = {\n";
|
2010-01-01 10:31:22 +00:00
|
|
|
|
2012-08-15 19:34:23 +00:00
|
|
|
i++;
|
2010-01-01 10:31:22 +00:00
|
|
|
|
2012-08-15 19:34:23 +00:00
|
|
|
for (unsigned index = 0; index < NumInstructions; ++index) {
|
2010-01-01 10:31:22 +00:00
|
|
|
o.indent(i * 2) << "{ /* " << index << " */" << "\n";
|
|
|
|
i++;
|
2012-04-14 13:54:10 +00:00
|
|
|
|
|
|
|
o.indent(i * 2) << stringForModifierType(
|
|
|
|
(ModifierType)InstructionSpecifiers[index].modifierType);
|
2012-08-15 19:34:23 +00:00
|
|
|
o << ",\n";
|
2012-04-14 13:54:10 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
o.indent(i * 2) << "0x";
|
|
|
|
o << format("%02hhx", (uint16_t)InstructionSpecifiers[index].modifierBase);
|
2012-08-15 19:34:23 +00:00
|
|
|
o << ",\n";
|
|
|
|
|
|
|
|
OperandListTy OperandList;
|
|
|
|
for (unsigned OperandIndex = 0; OperandIndex < X86_MAX_OPERANDS;
|
|
|
|
++OperandIndex) {
|
|
|
|
const char *Encoding =
|
|
|
|
stringForOperandEncoding((OperandEncoding)InstructionSpecifiers[index]
|
|
|
|
.operands[OperandIndex].encoding);
|
|
|
|
const char *Type =
|
|
|
|
stringForOperandType((OperandType)InstructionSpecifiers[index]
|
|
|
|
.operands[OperandIndex].type);
|
|
|
|
OperandList.push_back(std::make_pair(Encoding, Type));
|
2010-01-01 10:31:22 +00:00
|
|
|
}
|
2012-08-15 19:34:23 +00:00
|
|
|
o.indent(i * 2) << (OperandSets[OperandList] - 1) << ",\n";
|
2010-01-01 10:31:22 +00:00
|
|
|
|
2012-04-14 13:54:10 +00:00
|
|
|
o.indent(i * 2) << "/* " << InstructionSpecifiers[index].name << " */";
|
2010-01-01 10:31:22 +00:00
|
|
|
o << "\n";
|
|
|
|
|
|
|
|
i--;
|
|
|
|
o.indent(i * 2) << "}";
|
|
|
|
|
2012-08-15 19:34:23 +00:00
|
|
|
if (index + 1 < NumInstructions)
|
2010-01-01 10:31:22 +00:00
|
|
|
o << ",";
|
|
|
|
|
|
|
|
o << "\n";
|
|
|
|
}
|
|
|
|
|
|
|
|
i--;
|
|
|
|
o.indent(i * 2) << "};" << "\n";
|
|
|
|
}
|
|
|
|
|
2012-08-15 19:34:23 +00:00
|
|
|
void DisassemblerTables::emitContextTable(raw_ostream &o, unsigned &i) const {
|
|
|
|
o.indent(i * 2) << "static const uint8_t " CONTEXTS_STR
|
2011-02-20 12:57:14 +00:00
|
|
|
"[256] = {\n";
|
2010-01-01 10:31:22 +00:00
|
|
|
i++;
|
|
|
|
|
2012-08-15 19:34:23 +00:00
|
|
|
for (unsigned index = 0; index < 256; ++index) {
|
2010-01-01 10:31:22 +00:00
|
|
|
o.indent(i * 2);
|
|
|
|
|
2012-04-14 13:54:10 +00:00
|
|
|
if ((index & ATTR_VEXL) && (index & ATTR_REXW) && (index & ATTR_OPSIZE))
|
|
|
|
o << "IC_VEX_L_W_OPSIZE";
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
else if ((index & ATTR_VEXL) && (index & ATTR_REXW) && (index & ATTR_XD))
|
|
|
|
o << "IC_VEX_L_W_XD";
|
|
|
|
else if ((index & ATTR_VEXL) && (index & ATTR_REXW) && (index & ATTR_XS))
|
|
|
|
o << "IC_VEX_L_W_XS";
|
|
|
|
else if ((index & ATTR_VEXL) && (index & ATTR_REXW))
|
|
|
|
o << "IC_VEX_L_W";
|
2012-04-14 13:54:10 +00:00
|
|
|
else if ((index & ATTR_VEXL) && (index & ATTR_OPSIZE))
|
2011-05-02 19:34:44 +00:00
|
|
|
o << "IC_VEX_L_OPSIZE";
|
|
|
|
else if ((index & ATTR_VEXL) && (index & ATTR_XD))
|
|
|
|
o << "IC_VEX_L_XD";
|
|
|
|
else if ((index & ATTR_VEXL) && (index & ATTR_XS))
|
|
|
|
o << "IC_VEX_L_XS";
|
|
|
|
else if ((index & ATTR_VEX) && (index & ATTR_REXW) && (index & ATTR_OPSIZE))
|
|
|
|
o << "IC_VEX_W_OPSIZE";
|
|
|
|
else if ((index & ATTR_VEX) && (index & ATTR_REXW) && (index & ATTR_XD))
|
|
|
|
o << "IC_VEX_W_XD";
|
|
|
|
else if ((index & ATTR_VEX) && (index & ATTR_REXW) && (index & ATTR_XS))
|
|
|
|
o << "IC_VEX_W_XS";
|
|
|
|
else if (index & ATTR_VEXL)
|
|
|
|
o << "IC_VEX_L";
|
|
|
|
else if ((index & ATTR_VEX) && (index & ATTR_REXW))
|
|
|
|
o << "IC_VEX_W";
|
|
|
|
else if ((index & ATTR_VEX) && (index & ATTR_OPSIZE))
|
|
|
|
o << "IC_VEX_OPSIZE";
|
|
|
|
else if ((index & ATTR_VEX) && (index & ATTR_XD))
|
|
|
|
o << "IC_VEX_XD";
|
|
|
|
else if ((index & ATTR_VEX) && (index & ATTR_XS))
|
|
|
|
o << "IC_VEX_XS";
|
2011-10-20 21:10:27 +00:00
|
|
|
else if (index & ATTR_VEX)
|
|
|
|
o << "IC_VEX";
|
2011-05-02 19:34:44 +00:00
|
|
|
else if ((index & ATTR_64BIT) && (index & ATTR_REXW) && (index & ATTR_XS))
|
2010-01-01 10:31:22 +00:00
|
|
|
o << "IC_64BIT_REXW_XS";
|
|
|
|
else if ((index & ATTR_64BIT) && (index & ATTR_REXW) && (index & ATTR_XD))
|
|
|
|
o << "IC_64BIT_REXW_XD";
|
2012-08-15 19:34:23 +00:00
|
|
|
else if ((index & ATTR_64BIT) && (index & ATTR_REXW) &&
|
2010-01-01 10:31:22 +00:00
|
|
|
(index & ATTR_OPSIZE))
|
|
|
|
o << "IC_64BIT_REXW_OPSIZE";
|
2011-10-20 21:10:27 +00:00
|
|
|
else if ((index & ATTR_64BIT) && (index & ATTR_XD) && (index & ATTR_OPSIZE))
|
|
|
|
o << "IC_64BIT_XD_OPSIZE";
|
|
|
|
else if ((index & ATTR_64BIT) && (index & ATTR_XS) && (index & ATTR_OPSIZE))
|
|
|
|
o << "IC_64BIT_XS_OPSIZE";
|
2010-01-01 10:31:22 +00:00
|
|
|
else if ((index & ATTR_64BIT) && (index & ATTR_XS))
|
|
|
|
o << "IC_64BIT_XS";
|
|
|
|
else if ((index & ATTR_64BIT) && (index & ATTR_XD))
|
|
|
|
o << "IC_64BIT_XD";
|
|
|
|
else if ((index & ATTR_64BIT) && (index & ATTR_OPSIZE))
|
|
|
|
o << "IC_64BIT_OPSIZE";
|
2012-04-14 13:54:10 +00:00
|
|
|
else if ((index & ATTR_64BIT) && (index & ATTR_ADSIZE))
|
|
|
|
o << "IC_64BIT_ADSIZE";
|
2010-01-01 10:31:22 +00:00
|
|
|
else if ((index & ATTR_64BIT) && (index & ATTR_REXW))
|
|
|
|
o << "IC_64BIT_REXW";
|
|
|
|
else if ((index & ATTR_64BIT))
|
|
|
|
o << "IC_64BIT";
|
2011-10-20 21:10:27 +00:00
|
|
|
else if ((index & ATTR_XS) && (index & ATTR_OPSIZE))
|
|
|
|
o << "IC_XS_OPSIZE";
|
|
|
|
else if ((index & ATTR_XD) && (index & ATTR_OPSIZE))
|
|
|
|
o << "IC_XD_OPSIZE";
|
2010-01-01 10:31:22 +00:00
|
|
|
else if (index & ATTR_XS)
|
|
|
|
o << "IC_XS";
|
|
|
|
else if (index & ATTR_XD)
|
|
|
|
o << "IC_XD";
|
|
|
|
else if (index & ATTR_OPSIZE)
|
|
|
|
o << "IC_OPSIZE";
|
2012-04-14 13:54:10 +00:00
|
|
|
else if (index & ATTR_ADSIZE)
|
|
|
|
o << "IC_ADSIZE";
|
2010-01-01 10:31:22 +00:00
|
|
|
else
|
|
|
|
o << "IC";
|
|
|
|
|
|
|
|
if (index < 255)
|
|
|
|
o << ",";
|
|
|
|
else
|
|
|
|
o << " ";
|
|
|
|
|
|
|
|
o << " /* " << index << " */";
|
|
|
|
|
|
|
|
o << "\n";
|
|
|
|
}
|
|
|
|
|
|
|
|
i--;
|
|
|
|
o.indent(i * 2) << "};" << "\n";
|
|
|
|
}
|
|
|
|
|
2012-08-15 19:34:23 +00:00
|
|
|
void DisassemblerTables::emitContextDecisions(raw_ostream &o1, raw_ostream &o2,
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
unsigned &i1, unsigned &i2,
|
|
|
|
unsigned &ModRMTableNum) const {
|
|
|
|
emitContextDecision(o1, o2, i1, i2, ModRMTableNum, *Tables[0], ONEBYTE_STR);
|
|
|
|
emitContextDecision(o1, o2, i1, i2, ModRMTableNum, *Tables[1], TWOBYTE_STR);
|
|
|
|
emitContextDecision(o1, o2, i1, i2, ModRMTableNum, *Tables[2], THREEBYTE38_STR);
|
|
|
|
emitContextDecision(o1, o2, i1, i2, ModRMTableNum, *Tables[3], THREEBYTE3A_STR);
|
|
|
|
emitContextDecision(o1, o2, i1, i2, ModRMTableNum, *Tables[4], THREEBYTEA6_STR);
|
|
|
|
emitContextDecision(o1, o2, i1, i2, ModRMTableNum, *Tables[5], THREEBYTEA7_STR);
|
|
|
|
emitContextDecision(o1, o2, i1, i2, ModRMTableNum, *Tables[6], XOP8_MAP_STR);
|
|
|
|
emitContextDecision(o1, o2, i1, i2, ModRMTableNum, *Tables[7], XOP9_MAP_STR);
|
|
|
|
emitContextDecision(o1, o2, i1, i2, ModRMTableNum, *Tables[8], XOPA_MAP_STR);
|
2010-01-01 10:31:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void DisassemblerTables::emit(raw_ostream &o) const {
|
2012-08-15 19:34:23 +00:00
|
|
|
unsigned i1 = 0;
|
|
|
|
unsigned i2 = 0;
|
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
std::string s1;
|
|
|
|
std::string s2;
|
2012-08-15 19:34:23 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
raw_string_ostream o1(s1);
|
|
|
|
raw_string_ostream o2(s2);
|
2012-08-15 19:34:23 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
emitInstructionInfo(o, i2);
|
|
|
|
o << "\n";
|
|
|
|
|
|
|
|
emitContextTable(o, i2);
|
|
|
|
o << "\n";
|
2012-04-14 13:54:10 +00:00
|
|
|
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
unsigned ModRMTableNum = 0;
|
|
|
|
|
2012-04-14 13:54:10 +00:00
|
|
|
o << "static const InstrUID modRMTable[] = {\n";
|
|
|
|
i1++;
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
std::vector<unsigned> EmptyTable(1, 0);
|
|
|
|
ModRMTable[EmptyTable] = ModRMTableNum;
|
|
|
|
ModRMTableNum += EmptyTable.size();
|
|
|
|
o1 << "/* EmptyTable */\n";
|
|
|
|
o1.indent(i1 * 2) << "0x0,\n";
|
2012-04-14 13:54:10 +00:00
|
|
|
i1--;
|
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259
snapshot with the addition of threaded inferior support and a few bug
fixes.
Specific upstream lldb revisions restored include:
SVN git
181387 779e6ac
181703 7bef4e2
182099 b31044e
182650 f2dcf35
182683 0d91b80
183862 15c1774
183929 99447a6
184177 0b2934b
184948 4dc3761
184954 007e7bc
186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional
impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD
is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty
when PWD can't be determined. This way, MCJIT clients,
and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done
only for clients of getCompilationDir(). This is as simple as checking
for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which
won't conceivably run with an invalid working dir. However, in the
purely hypothetically and untestable case that this happens, the
AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox,
when it is using jails, and sometimes invalidates clang's current
working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with
regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current
PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it
was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories
in clang's InitHeaderSearch.cpp. This has been superseded by David
Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should
not be in the search path at all. These directories are now only used
if you pass -stdlib=libstdc++.
2014-03-21 17:53:59 +00:00
|
|
|
emitContextDecisions(o1, o2, i1, i2, ModRMTableNum);
|
2012-04-14 13:54:10 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
o << o1.str();
|
2012-04-14 13:54:10 +00:00
|
|
|
o << " 0x0\n";
|
|
|
|
o << "};\n";
|
2010-01-01 10:31:22 +00:00
|
|
|
o << "\n";
|
|
|
|
o << o2.str();
|
|
|
|
o << "\n";
|
|
|
|
o << "\n";
|
|
|
|
}
|
|
|
|
|
|
|
|
void DisassemblerTables::setTableFields(ModRMDecision &decision,
|
|
|
|
const ModRMFilter &filter,
|
|
|
|
InstrUID uid,
|
|
|
|
uint8_t opcode) {
|
2012-08-15 19:34:23 +00:00
|
|
|
for (unsigned index = 0; index < 256; ++index) {
|
2010-01-01 10:31:22 +00:00
|
|
|
if (filter.accepts(index)) {
|
|
|
|
if (decision.instructionIDs[index] == uid)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (decision.instructionIDs[index] != 0) {
|
|
|
|
InstructionSpecifier &newInfo =
|
|
|
|
InstructionSpecifiers[uid];
|
|
|
|
InstructionSpecifier &previousInfo =
|
|
|
|
InstructionSpecifiers[decision.instructionIDs[index]];
|
2012-08-15 19:34:23 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
if(newInfo.filtered)
|
|
|
|
continue; // filtered instructions get lowest priority
|
2012-08-15 19:34:23 +00:00
|
|
|
|
2011-10-20 21:10:27 +00:00
|
|
|
if(previousInfo.name == "NOOP" && (newInfo.name == "XCHG16ar" ||
|
|
|
|
newInfo.name == "XCHG32ar" ||
|
|
|
|
newInfo.name == "XCHG32ar64" ||
|
|
|
|
newInfo.name == "XCHG64ar"))
|
|
|
|
continue; // special case for XCHG*ar and NOOP
|
2010-01-01 10:31:22 +00:00
|
|
|
|
|
|
|
if (outranks(previousInfo.insnContext, newInfo.insnContext))
|
|
|
|
continue;
|
2012-08-15 19:34:23 +00:00
|
|
|
|
2010-01-01 10:31:22 +00:00
|
|
|
if (previousInfo.insnContext == newInfo.insnContext &&
|
|
|
|
!previousInfo.filtered) {
|
|
|
|
errs() << "Error: Primary decode conflict: ";
|
|
|
|
errs() << newInfo.name << " would overwrite " << previousInfo.name;
|
|
|
|
errs() << "\n";
|
|
|
|
errs() << "ModRM " << index << "\n";
|
|
|
|
errs() << "Opcode " << (uint16_t)opcode << "\n";
|
|
|
|
errs() << "Context " << stringForContext(newInfo.insnContext) << "\n";
|
|
|
|
HasConflicts = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
decision.instructionIDs[index] = uid;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void DisassemblerTables::setTableFields(OpcodeType type,
|
|
|
|
InstructionContext insnContext,
|
|
|
|
uint8_t opcode,
|
|
|
|
const ModRMFilter &filter,
|
2011-10-20 21:10:27 +00:00
|
|
|
InstrUID uid,
|
|
|
|
bool is32bit,
|
|
|
|
bool ignoresVEX_L) {
|
2010-01-01 10:31:22 +00:00
|
|
|
ContextDecision &decision = *Tables[type];
|
|
|
|
|
2012-08-15 19:34:23 +00:00
|
|
|
for (unsigned index = 0; index < IC_max; ++index) {
|
2011-10-20 21:10:27 +00:00
|
|
|
if (is32bit && inheritsFrom((InstructionContext)index, IC_64BIT))
|
|
|
|
continue;
|
|
|
|
|
2012-08-15 19:34:23 +00:00
|
|
|
if (inheritsFrom((InstructionContext)index,
|
2011-10-20 21:10:27 +00:00
|
|
|
InstructionSpecifiers[uid].insnContext, ignoresVEX_L))
|
2012-08-15 19:34:23 +00:00
|
|
|
setTableFields(decision.opcodeDecisions[index].modRMDecisions[opcode],
|
2010-01-01 10:31:22 +00:00
|
|
|
filter,
|
|
|
|
uid,
|
|
|
|
opcode);
|
|
|
|
}
|
|
|
|
}
|