Summary:
  - For x86_64-FreeBSD Platform:
    -- LLDB now provides correct values of X87 FPU
       Special Purpose Registers like fstat, ftag, fctrl etc..

Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>

Reviewers: emaste, mikesart, clayborg

Subscribers: emaste

Differential Revision: http://reviews.llvm.org/D13434

llvm-svn: 249379

[TwoAddressInstructionPass] When looking for a 3 addr conversion after commuting, make sure regB has been updated to take into account the commute.

llvm-svn: 249378

Reviewers: clayborg, jingham.
Subscribers: jaydeep, bhushan, dsanders, sagar, nitesh.jain, zturner, jasonmolenda, lldb-commits.
Differential Revision: http://reviews.llvm.org/D13241

llvm-svn: 249377

Unfortunately, int_utils.h needs to depend on int_lib for the common macro
definitions.  However, currently, int_utils.h is included by int_lib.h.  Reorder
the inclusion to work around this.

llvm-svn: 249376

This allows us to build the builtins using MSVC.  NFC.

Patch by Tee Hao Wei!

llvm-svn: 249375

Use 4294967296.f instead of 0x1p32f to fix MSVC.  NFC.

Patch by Tee Hao Wei!

llvm-svn: 249374

Include Windows.h instead of winbase.h and windef.h

Patch by Tee Hao Wei!

llvm-svn: 249373

llvm-svn: 249372

For the program like below
struct key_t {
  int pid;
  char name[16];
};
extern void test1(char *);
int test() {
  struct key_t key = {};
  test1(key.name);
  return 0;
}
For key.name, the llc/bpf may generate the below code:
  R1 = R10  // R10 is the frame pointer
  R1 += -24 // framepointer adjustment
  R1 |= 4   // R1 is then used as the first parameter of test1
OR operation is not recognized by in-kernel verifier.

This patch introduces an intermediate FI_ri instruction and
generates the following code that can be properly verified:
  R1 = R10
  R1 += -20

Patch by Yonghong Song <yhs@plumgrid.com>

llvm-svn: 249371

[X86] Teach constant hoisting that ANDs with 64-bit immediates in the range 0x80000000-0xffffffff can be handled cheaply and don't need to be hoisted.

Most importantly, this keeps constant hoisting from preventing instruction selections ability to turn an AND with 0xffffffff into a move into a 32-bit subregister.

llvm-svn: 249370

[X86] Remove unnecessary AddComplexity directive. The instruction is already wrapped in the equivalent earlier. NFC

llvm-svn: 249369

llvm-svn: 249368

llvm-svn: 249367

Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be

This is a NFC commit that is essentially plumbing the new currency through the system

llvm-svn: 249366

llvm-svn: 249365

This new syntax is built around putting each instruction on its own line
in a "mnemonic op, op, op" like syntax. It also uses conventional data
section directives like ".byte" and so on rather than requiring everything
to be in hierarchical S-expression format. This is a more natural syntax
for a ".s" file format from the perspective of LLVM MC and related tools,
while remaining easy to translate into other forms as needed.

llvm-svn: 249364

llvm-svn: 249363

if there exists not definition for the type.
For this to work, we need to clone the imported modules before building
the decl context chains of the DIEs in the non-skeleton CUs.

llvm-svn: 249362

SBTarget::Attach(SBAttachInfo &) was changed to not be asynchronous back in February and this affected Xcode's abililty to cancel an attach to process by name.

Added the ability to specify if an attach by name should be synchronous or not in SBAttachInfo and ProcessAttachInfo.

<rdar://problem/22821480>

llvm-svn: 249361

We were mixing up the relocated and target sections.

llvm-svn: 249360

This was clearly wrong (thanks Rui for spotting), and I honestly would 
like to get this tested so such mistakes won't repeat. Unfortunately, I
wasn't (easily) able to craft a test that exposes the bad behavior.
Ideally, we would like to get tests of this kind for all relocations, but
at the time of writing, this is not true. So, for now just fix this bug
and try to re-evaluate a way to test this in the future.

llvm-svn: 249359

Summary: This is the Makefile analog of r247833, except that the test also had to be changed such that clang actually attempts to link the program as opposed to just building it. Because of that change, I also switched the order to checking for ld/clang architecture support, because now lack of ld support would make the clang check fail. This fixes PR24776.

Reviewers: beanz

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D13425

llvm-svn: 249358

llvm-svn: 249357

llvm-svn: 249356

llvm-svn: 249355

llvm-svn: 249354

llvm-svn: 249353

llvm-svn: 249352

Given the work we are doing on ThinLTO, we will never need to support
module groups and working sets in GCC's implementation of LIPO. These
are currently dead code, and will continue to be so.

llvm-svn: 249351

Before the ADDR variables could match the empty string.

llvm-svn: 249350

llvm-svn: 249349

llvm-svn: 249348

llvm-svn: 249347

No idea what asymmetry MSVC is findind.

llvm-svn: 249346

llvm-svn: 249345

The CATCHRET operand did not match the MachineFunction's CFG.  This
mismatch happened because FrameLowering created a new MachineBasicBlock
and updated the CFG but forgot to update the CATCHRET operand.

Let's make sure this doesn't happen again by strengthing the funclet
membership analysis: it can now reason about the membership of all basic
blocks, not just those inside of funclets.

llvm-svn: 249344

Adding a checker (cert-dcl50-cpp) that detects the definition of a C-style variadic function in C++ code. Corresponds to the CERT C++ secure coding rule: https://www.securecoding.cert.org/confluence/display/cplusplus/DCL50-CPP.+Do+not+define+a+C-style+variadic+function

llvm-svn: 249343

that change turns out to not be reasonable: mutating the AST of a parsed
template during instantiation is not a sound thing to do, does not work across
chained PCH / modules builds, and is in any case a special-case workaround to a
more general problem that should be solved centrally.

llvm-svn: 249342

llvm-svn: 249341

The dynamic relocation code needs refactoring, but it is probably better
to do it with this test passing.

llvm-svn: 249340