into OptimizeCompareInstr.
This necessitates the passing of CmpValue around,
so widen the virtual functions to accomodate.

No functionality changes.

llvm-svn: 114428

llvm-svn: 114427

Fixes rdar://8331312.

llvm-svn: 114426

pass a completely incorrect SrcValue, which would result in a miscompile with
combiner-aa.

llvm-svn: 114411

llvm-svn: 114410

llvm-svn: 114409

"getFixedStack" on the MachinePointerInfo class.  While
this isn't the problem I'm setting out to solve, it is the
right way to eliminate PseudoSourceValue, so lets go with it.

llvm-svn: 114406

llvm-svn: 114405

of the getLoad methods.  This fixes at least one bug where an incorrect
svoffset is passed in (a potential combiner-aa miscompile).

llvm-svn: 114404

- definitions of interfaces for CFGInitializer and CFGAutomaticObjDtor,
- support for above classes to print_elem function (renamed print_stmt),
- support for VarDecls in StmtPrinterHelper.

llvm-svn: 114403

into non-segment-relative copies.

llvm-svn: 114402

instead of srcvalue/offset pairs.  This corrects SV info for mem 
operations whose size is > 32-bits.

llvm-svn: 114401

llvm-svn: 114400

MachinePointerInfo.  Among other virtues, this doesn't silently  truncate the
svoffset to 32-bits.

llvm-svn: 114399

llvm-svn: 114397

eliminating some weird "infer a frame address" logic which was dead.

llvm-svn: 114396

llvm-svn: 114395

llvm-svn: 114394

MachinePointerInfo, propagating the type out a level of API.  Remove
the old MachineFunction::getMachineMemOperand impl.

llvm-svn: 114393

Check for null ObjCInterfaceDecls returned from getClassInterface() when generating USRs.  While I have no test case for this (could not create one), this shows up in crash reports.  Tentatively fixes <rdar://problem/8452791>.

llvm-svn: 114392

llvm-svn: 114391

to the MachineFunction construction methods.

llvm-svn: 114390

MachinePointerInfo struct, no functionality change.

This also adds an assert to MachineMemOperand::MachineMemOperand
that verifies that the Value* is either null or is an IR pointer type.

llvm-svn: 114389

llvm-svn: 114387

For now, just disable folding the load into the call.

llvm-svn: 114386

doing with them. It's a "FIXME" right now because this change hasn't been
implemented yet.

llvm-svn: 114385

for C++ classes.  Replaced it with a less hacky approach:

 - If an expression is defined in the context of a
   method of class A, then that expression is wrapped as
   ___clang_class::___clang_expr(void*) { ... }
   instead of ___clang_expr(void*) { ... }.

 - ___clang_class is resolved as the type of the target
   of the "this" pointer in the method the expression
   is defined in.

 - When reporting the type of ___clang_class, a method
   with the signature ___clang_expr(void*) is added to
   that class, so that Clang doesn't complain about a
   method being defined without a corresponding
   declaration.

 - Whenever the expression gets called, "this" gets
   looked up, type-checked, and then passed in as the
   first argument.

This required the following changes:

 - The ABIs were changed to support passing of the "this"
   pointer as part of trivial calls.

 - ThreadPlanCallFunction and ClangFunction were changed
   to support passing of an optional "this" pointer.

 - ClangUserExpression was extended to perform the
   wrapping described above.

 - ClangASTSource was changed to revert the changes
   required by the hack.

 - ClangExpressionParser, IRForTarget, and
   ClangExpressionDeclMap were changed to handle
   different manglings of ___clang_expr flexibly.  This
   meant no longer searching for a function called
   ___clang_expr, but rather looking for a function whose
   name *contains* ___clang_expr.

 - ClangExpressionParser and ClangExpressionDeclMap now
   remember whether "this" is required, and know how to
   look it up as necessary.

A few inheritance bugs remain, and I'm trying to resolve
these.  But it is now possible to use "this" as well as
refer implicitly to member variables, when in the proper
context.

llvm-svn: 114384

llvm-svn: 114383

llvm-svn: 114382

llvm-svn: 114381

order to customize the running of the test suite.  For the time being, the
supported customizations are:

o redirecting stdout and/or stderr
o specifying a list of compilers to build the test programs
o specifying a list of architectures to build the test programs for

Also checked into the examples/test directory some example files which
demonstrate the usage for the above customizations.

$ ./dotest.py -v -c ~/.lldbtest-config persistent_variables
$ cat ~/.lldbtest-config
sys.stderr = open("/tmp/lldbtest-stderr", "w")
sys.stdout = open("/tmp/lldbtest-stdout", "w")
compilers = ["gcc", "llvm-gcc"]
archs = ["x86_64", "i386"]
$ cat /tmp/lldbtest-stderr
----------------------------------------------------------------------
Collected 1 test


Configuration: arch=x86_64 compiler=gcc
test_persistent_variables (TestPersistentVariables.PersistentVariablesTestCase)
Test that lldb persistent variables works correctly. ... ok

----------------------------------------------------------------------
Ran 1 test in 1.397s

OK

Configuration: arch=x86_64 compiler=llvm-gcc
test_persistent_variables (TestPersistentVariables.PersistentVariablesTestCase)
Test that lldb persistent variables works correctly. ... ok

----------------------------------------------------------------------
Ran 1 test in 1.282s

OK

Configuration: arch=i386 compiler=gcc
test_persistent_variables (TestPersistentVariables.PersistentVariablesTestCase)
Test that lldb persistent variables works correctly. ... ok

----------------------------------------------------------------------
Ran 1 test in 1.297s

OK

Configuration: arch=i386 compiler=llvm-gcc
test_persistent_variables (TestPersistentVariables.PersistentVariablesTestCase)
Test that lldb persistent variables works correctly. ... ok

----------------------------------------------------------------------
Ran 1 test in 1.269s

OK
$ cat /tmp/lldbtest-stdout
$ 

llvm-svn: 114380

message send, e.g.,

  [[NSString alloc] initWithCString:<CC>

look up all of the possible methods and determine the preferred type
for the argument expression based on the type of the corresponding
parameter.

llvm-svn: 114379

stderr so as not to disrupt the information emitted by the unittest framework.

llvm-svn: 114377

complex conditionals. Radar 8453812.

llvm-svn: 114376

Objective-C message sends. There is no functionality change here; this
is prep work for using the parameter types to help guide the
expression results when code-completing the argument.

llvm-svn: 114375

at the statement level or in Objective-C message receivers. Therefore,
just give types and declarations the same basic priority, and adjust
from there.

llvm-svn: 114374

define double @foo(double %x, double %y, i1 %c) nounwind {
  %a = fdiv double %x, 3.2
  %z = select i1 %c, double %a, double %y
  ret double %z
}

Was:
_foo:
        divsd   LCPI0_0(%rip), %xmm0
        testb   $1, %dil
        jne     LBB0_2
        movaps  %xmm1, %xmm0
LBB0_2:
        ret

Now:
_foo:
        testb   $1, %dil
        je      LBB0_2
        divsd   LCPI0_0(%rip), %xmm0
        ret
LBB0_2:
        movaps  %xmm1, %xmm0
        ret

This avoids the divsd when early exit is taken.
rdar://8454886

llvm-svn: 114372

llvm-svn: 114371

various priority adjustments for preferences (based on selectors,
types) in a single function to make extension easier.

llvm-svn: 114370

from rdar://8452472. This unbreaks gcc.dg/builtins-17.c.

llvm-svn: 114368