| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 115792
|
| |
|
|
|
|
| |
unused argument here. This is a known limitation recorded debuginfo-tests/trunk/dbg-declare2.ll function 'f6' test case.
llvm-svn: 115323
|
| |
|
|
| |
llvm-svn: 115310
|
| |
|
|
| |
llvm-svn: 115300
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The x86_mmx type is used for MMX intrinsics, parameters and
return values where these use MMX registers, and is also
supported in load, store, and bitcast.
Only the above operations generate MMX instructions, and optimizations
do not operate on or produce MMX intrinsics.
MMX-sized vectors <2 x i32> etc. are lowered to XMM or split into
smaller pieces. Optimizations may occur on these forms and the
result casted back to x86_mmx, provided the result feeds into a
previous existing x86_mmx operation.
The point of all this is prevent optimizations from introducing
MMX operations, which is unsafe due to the EMMS problem.
llvm-svn: 115243
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
edited during emission.
If the basic block ends in a switch that gets lowered to a jump table, any
phis at the default edge were getting updated wrong. The jump table data
structure keeps a pointer to the header blocks that wasn't getting updated
after the MBB is split.
This bug was exposed on 32-bit Linux when disabling critical edge splitting in
codegen prepare.
The fix is to uipdate stale MBB pointers whenever a block is split during
emission.
llvm-svn: 115191
|
| |
|
|
| |
llvm-svn: 114767
|
| |
|
|
| |
llvm-svn: 114750
|
| |
|
|
|
|
| |
doubt it but it's possible it's exposing another bug somewhere.
llvm-svn: 114681
|
| |
|
|
|
|
| |
conditional one.
llvm-svn: 114634
|
| |
|
|
|
|
|
|
|
|
|
|
| |
when the unconditional branch destination is the fallthrough block. The
canonicalization makes it easier to allow optimizations on DAGs to invert
conditional branches. The branch folding pass (and AnalyzeBranch) will clean up
the unnecessary unconditional branches later.
This is one of the patches leading up to disabling codegen prepare critical edge
splitting.
llvm-svn: 114630
|
| |
|
|
|
|
|
| |
I think I've audited all uses, so it should be dependable for address spaces,
and the pointer+offset info should also be accurate when there.
llvm-svn: 114464
|
| |
|
|
|
|
| |
and store intrinsics are represented with MemIntrinsicSDNodes.
llvm-svn: 114454
|
| |
|
|
|
|
| |
getLoad overloads.
llvm-svn: 114443
|
| |
|
|
|
|
|
| |
instead of srcvalue/offset pairs. This corrects SV info for mem
operations whose size is > 32-bits.
llvm-svn: 114401
|
| |
|
|
|
|
| |
MachinePointerInfo
llvm-svn: 114397
|
| |
|
|
|
|
| |
eliminating some weird "infer a frame address" logic which was dead.
llvm-svn: 114396
|
| |
|
|
|
|
| |
This fixes funcargs.exp regression reported by gdb testsuite.
llvm-svn: 113992
|
| |
|
|
|
|
| |
use offset available in StaticAllocaMap to emit DBG_VALUE. Right now, this has no material impact because varible info also collected using offset table maintained in machine module info.
llvm-svn: 113967
|
| |
|
|
| |
llvm-svn: 113766
|
| |
|
|
| |
llvm-svn: 112864
|
| |
|
|
| |
llvm-svn: 112858
|
| |
|
|
| |
llvm-svn: 112659
|
| |
|
|
| |
llvm-svn: 112631
|
| |
|
|
|
|
|
|
| |
info to emit debug info.
Fixes Radar 8367011.
llvm-svn: 112623
|
| |
|
|
| |
llvm-svn: 112584
|
| |
|
|
|
|
| |
being actively maintained, improved, or extended.
llvm-svn: 112356
|
| |
|
|
|
|
| |
doesn't currently support dealing with this.
llvm-svn: 112341
|
| |
|
|
| |
llvm-svn: 112305
|
| |
|
|
| |
llvm-svn: 112242
|
| |
|
|
|
|
| |
byval parameter.
llvm-svn: 112238
|
| |
|
|
| |
llvm-svn: 112216
|
| |
|
|
| |
llvm-svn: 112215
|
| |
|
|
| |
llvm-svn: 112213
|
| |
|
|
|
|
| |
register, used for a value, is initialized after a dbg intrinsic is seen.
llvm-svn: 112207
|
| |
|
|
| |
llvm-svn: 112155
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expanding: e.g. <2 x float> -> <4 x float> instead of -> 2 floats. This
affects two places in the code: handling cross block values and handling
function return and arguments. Since vectors are already widened by
legalizetypes, this gives us much better code and unblocks x86-64 abi
and SPU abi work.
For example, this (which is a silly example of a cross-block value):
define <4 x float> @test2(<4 x float> %A) nounwind {
%B = shufflevector <4 x float> %A, <4 x float> undef, <2 x i32> <i32 0, i32 1>
%C = fadd <2 x float> %B, %B
br label %BB
BB:
%D = fadd <2 x float> %C, %C
%E = shufflevector <2 x float> %D, <2 x float> undef, <4 x i32> <i32 0, i32 1, i32 undef, i32 undef>
ret <4 x float> %E
}
Now compiles into:
_test2: ## @test2
## BB#0:
addps %xmm0, %xmm0
addps %xmm0, %xmm0
ret
previously it compiled into:
_test2: ## @test2
## BB#0:
addps %xmm0, %xmm0
pshufd $1, %xmm0, %xmm1
## kill: XMM0<def> XMM0<kill> XMM0<def>
insertps $0, %xmm0, %xmm0
insertps $16, %xmm1, %xmm0
addps %xmm0, %xmm0
ret
This implements rdar://8230384
llvm-svn: 112101
|
| |
|
|
| |
llvm-svn: 112085
|
| |
|
|
|
|
| |
no functionality change.
llvm-svn: 111994
|
| |
|
|
|
|
| |
functionality change.
llvm-svn: 111990
|
| |
|
|
| |
llvm-svn: 109415
|
| |
|
|
|
|
|
|
| |
information.
No functional change yet.
llvm-svn: 108583
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
since it doesn't work for front-ends which don't emit column information
(which includes llvm-gcc in its present configuration), and doesn't
work for clang for K&R style variables where the variables are declared
in a different order from the parameter list.
Instead, make a separate pass through the instructions to collect the
llvm.dbg.declare instructions in order. This ensures that the debug
information for variables is emitted in this order.
llvm-svn: 108538
|
| |
|
|
|
|
|
|
|
|
| |
occasions, caused code to be generated in a different order.
All cases I've seen involved float softening in the type
legalizer, and this could be perhaps be fixed there, but
it's better not to generate things differently in the first
place. 7797940 (6/29/2010..7/15/2010).
llvm-svn: 108484
|
| |
|
|
| |
llvm-svn: 108478
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the function. We'll just turn it into a "trap" instruction instead.
The problem with not handling this is that it might generate a prologue without
the equivalent epilogue to go with it:
$ cat t.ll
define void @foo() {
entry:
unreachable
}
$ llc -o - t.ll -relocation-model=pic -disable-fp-elim -unwind-tables
.section __TEXT,__text,regular,pure_instructions
.globl _foo
.align 4, 0x90
_foo: ## @foo
Leh_func_begin0:
## BB#0: ## %entry
pushq %rbp
Ltmp0:
movq %rsp, %rbp
Ltmp1:
Leh_func_end0:
...
The unwind tables then have bad data in them causing all sorts of problems.
Fixes <rdar://problem/8096481>.
llvm-svn: 108473
|
| |
|
|
| |
llvm-svn: 108381
|
| |
|
|
|
|
|
| |
This may not be right in all cases, but it's better
than asserting which it was doing before. PR 7528.
llvm-svn: 108268
|
| |
|
|
| |
llvm-svn: 108164
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
correct alignment information, which simplifies ExpandRes_VAARG a bit.
The patch introduces a new alignment information to TargetLoweringInfo. This is
needed since the two natural candidates cannot be used:
* The 's' in target data: If this is set to the minimal alignment of any
argument, getCallFrameTypeAlignment would return 4 for doubles on ARM for
example.
* The getTransientStackAlignment method. It is possible for an architecture to
have argument less aligned than what we maintain the stack pointer.
llvm-svn: 108072
|