This will work better for the disassembler for modeling things
like lfence/monitor/vmcall etc.

llvm-svn: 95960

llvm-svn: 95959

great solution for the disassembler, we'll go with "plan b".

llvm-svn: 95957

matcher is now free of implicit operands!
 - Still need to clean up the code now that we don't to worry about implicit
   operands, and to make it a hard error if an instruction fails to specify all
   of its operands for some reason.

llvm-svn: 95956

MRRC, MRRc2.  For disassembly only.

llvm-svn: 95955

llvm-svn: 95954

llvm-svn: 95953

llvm-svn: 95952

reduce down to a single value.  InstCombine already does this transformation
but DAG legalization may introduce new opportunities.  This has turned out to
be important for ARM where 64-bit values are split up during type legalization:
InstCombine is not able to remove the PHI cycles on the 64-bit values but
the separate 32-bit values can be optimized.  I measured the compile time 
impact of this (running llc on 176.gcc) and it was not significant.

llvm-svn: 95951

with "tied memory operands", which is wrong.

llvm-svn: 95950

llvm-svn: 95949

movq	(%ecx,%edx,2), %xmm2
movhps	(%ecx,%eax,2), %xmm2

rather than:

movq     (%eax, %edx, 2), %xmm2		
movq     (%eax, %ebx, 2), %xmm3		
movlhps  %xmm3, %xmm2			

Testcase forthcoming.

llvm-svn: 95948

busted in both encoders.  I'm not bothering to fix it in the
old one at this point.

llvm-svn: 95947

Kees van Reeuwijk!

llvm-svn: 95946

implement support for it) that the stack should be forcibly realigned in the
prologue (and the process reversed in the epilogue).

llvm-svn: 95945

(1) When no 'clang' is found with 'scan-build', remember the one from
the path as scan-build sees it, not the build system.  This prevents
us from finding different clangs during the build.

(2) Don't set LDPLUSPLUS when running xcodebuild; instead rely on the
clang driver to do the right thing.

llvm-svn: 95943

llvm-svn: 95942

llvm-svn: 95941

llvm-svn: 95940

pointer. If you don't like the new warning, you can turn it off with
-Wno-force-align-arg-pointer.

llvm-svn: 95939

This time with fixed test cases.

llvm-svn: 95938

order of constructor arguments (all block API specific). This was exposed only in 
a large block literal expression in a large file where PtrSet container size 
execceded its limit and required reallocation.  Fixes radar 7638294

llvm-svn: 95936

	testb	%al, %al                ## <MCInst #2412 TEST8rr
                                        ##   <MCOperand Reg:2>
                                        ##   <MCOperand Reg:2>>
	jne	LBB1_7                  ## <MCInst #938 JNE_1
                                        ##   <MCOperand Expr:(LBB1_7)>>

llvm-svn: 95935

variable type, we can (and should) still check for completeness of the
variable's type. Do so, to work around an assertion that shows up in
Boost's shared_ptr.

llvm-svn: 95934

Fix leak in CXXNewExpr where the SubExprs array would get allocated directly using 'new[]' instead of the allocator associated with ASTContext.

llvm-svn: 95933

MSVC build.

llvm-svn: 95932

Fix re-allocation in AttrWithString::ReplaceString() to use the allocator assosciated with ASTContext.

llvm-svn: 95931

Allocate the SubExprs array in ObjCMessageExpr using the allocator associated with ASTContext.  This fixes yet another leak (<rdar://problem/7639260>).

llvm-svn: 95930

implemented, llvm-mc --show-inst now uses it to print the
instruction opcode as well as the number.

llvm-svn: 95929

llvm-svn: 95928

8 or 32-bit immediates, which allows the new encoder to handle
them.

llvm-svn: 95927

llvm-svn: 95926

llvm-svn: 95925

the tables to be const.  Teach MCCodeEmitter to handle
the target-indep kinds so that we don't crash on them.

llvm-svn: 95924

llvm-svn: 95922

llvm-svn: 95921

llvm-svn: 95920

llvm-svn: 95918

Also avoid division by zero.

llvm-svn: 95917

llvm-svn: 95916