| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
Make sure functions located in user specified text sections (via the
section attribute) are located together with the default text sections.
Otherwise, for large object files, the relocations for call instructions
are more likely to be out of range. This becomes even more likely in the
presence of LTO.
rdar://12402636
llvm-svn: 165254
|
| |
|
|
|
|
|
|
|
|
|
| |
in the Intel syntax.
The MC layer supports emitting in the Intel syntax, but this would require the
inline assembly MachineInstr to be lowered to an MCInst before emission. This
is potential future work, but for now emitting directly from the MachineInstr
suffices.
llvm-svn: 165173
|
| |
|
|
|
|
|
|
|
|
|
| |
load and
multiple stores with a single load. We create the wide loads and stores (and their chains)
before we remove the scalar loads and stores and fix the DAG chain. We attempted to merge
loads with a different chain. When that happened, the assumption that it is safe to RAUW
broke and a cycle was introduced.
llvm-svn: 165148
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
optimization
is not profitable in many cases because modern processors perform multiple stores
in parallel and merging stores prior to merging requires extra work. We handle two main cases:
1. Store of multiple consecutive constants:
q->a = 3;
q->4 = 5;
In this case we store a single legal wide integer.
2. Store of multiple consecutive loads:
int a = p->a;
int b = p->b;
q->a = a;
q->b = b;
In this case we load/store either ilegal vector registers or legal wide integer registers.
llvm-svn: 165125
|
| |
|
|
|
|
| |
not propagate through implicit defs.
llvm-svn: 165102
|
| |
|
|
|
|
|
|
|
|
|
| |
Enable the pass by default for targets that request it, and change the
-enable-early-ifcvt to the opposite -disable-early-ifcvt.
There are still some x86 regressions when enabling early if-conversion
because of the missing machine models. Disable the pass for x86 until
machine models are added.
llvm-svn: 165075
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
X86DAGToDAGISel::PreprocessISelDAG(), isel is moving load inside
callseq_start / callseq_end so it can be folded into a call. This can
create a cycle in the DAG when the call is glued to a copytoreg. We
have been lucky this hasn't caused too many issues because the pre-ra
scheduler has special handling of call sequences. However, it has
caused a crash in a specific tailcall case.
rdar://12393897
llvm-svn: 165072
|
| |
|
|
| |
llvm-svn: 165063
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
JoinVals::pruneValues() calls LIS->pruneValue() to avoid conflicts when
overlapping two different values. This produces a set of live range end
points that are used to reconstruct the live range (with SSA update)
after joining the two registers.
When a value is pruned twice, the set of end points was insufficient:
v1 = DEF
v1 = REPLACE1
v1 = REPLACE2
KILL v1
The end point at KILL would only reconstruct the live range from
REPLACE2 to KILL, leaving the range REPLACE1-REPLACE2 dead.
Add REPLACE2 as an end point in this case so the full live range is
reconstructed.
This fixes PR13999.
llvm-svn: 165056
|
| |
|
|
| |
llvm-svn: 165019
|
| |
|
|
|
|
|
| |
the add/sub case since in the case of multiplication you also have to check that
the operation in the larger type did not overflow.
llvm-svn: 165017
|
| |
|
|
| |
llvm-svn: 164975
|
| |
|
|
|
|
| |
was already approved
llvm-svn: 164972
|
| |
|
|
|
|
|
|
|
| |
- Update maximal stack alignment when stack arguments are prepared before a
call.
- Test cases are enhanced to show it's not a Win32 specific issue but a generic
one.
llvm-svn: 164946
|
| |
|
|
| |
llvm-svn: 164911
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is not profitable in many cases
because moden processos can store multiple values in parallel, and preparing the consecutive store requires
some work. We only handle these cases:
1. Consecutive stores where the values and consecutive loads. For example:
int a = p->a;
int b = p->b;
q->a = a;
q->b = b;
2. Consecutive stores where the values are constants. Foe example:
q->a = 4;
q->b = 5;
llvm-svn: 164910
|
| |
|
|
| |
llvm-svn: 164899
|
| |
|
|
| |
llvm-svn: 164898
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
buildbots. Original commit message:
A DAGCombine optimization for merging consecutive stores. This optimization is not profitable in many cases
because moden processos can store multiple values in parallel, and preparing the consecutive store requires
some work. We only handle these cases:
1. Consecutive stores where the values and consecutive loads. For example:
int a = p->a;
int b = p->b;
q->a = a;
q->b = b;
2. Consecutive stores where the values are constants. Foe example:
q->a = 4;
q->b = 5;
llvm-svn: 164890
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is not profitable in many cases
because moden processos can store multiple values in parallel, and preparing the consecutive store requires
some work. We only handle these cases:
1. Consecutive stores where the values and consecutive loads. For example:
int a = p->a;
int b = p->b;
q->a = a;
q->b = b;
2. Consecutive stores where the values are constants. Foe example:
q->a = 4;
q->b = 5;
llvm-svn: 164885
|
| |
|
|
| |
llvm-svn: 164866
|
| |
|
|
| |
llvm-svn: 164849
|
| |
|
|
| |
llvm-svn: 164845
|
| |
|
|
| |
llvm-svn: 164842
|
| |
|
|
| |
llvm-svn: 164840
|
| |
|
|
|
|
|
| |
The new coalescer is better at merging values into unused vector lanes,
improving NEON code.
llvm-svn: 164794
|
| |
|
|
| |
llvm-svn: 164787
|
| |
|
|
| |
llvm-svn: 164786
|
| |
|
|
|
|
| |
Fixes PR13943.
llvm-svn: 164778
|
| |
|
|
|
|
|
| |
This is a preliminary step towards ELF support; currently ARMFastISel hasn't
been used for ELF object files yet.
llvm-svn: 164759
|
| |
|
|
| |
llvm-svn: 164757
|
| |
|
|
| |
llvm-svn: 164754
|
| |
|
|
|
|
| |
Field instruction.
llvm-svn: 164751
|
| |
|
|
| |
llvm-svn: 164750
|
| |
|
|
| |
llvm-svn: 164749
|
| |
|
|
| |
llvm-svn: 164744
|
| |
|
|
| |
llvm-svn: 164687
|
| |
|
|
| |
llvm-svn: 164685
|
| |
|
|
| |
llvm-svn: 164681
|
| |
|
|
| |
llvm-svn: 164675
|
| |
|
|
| |
llvm-svn: 164674
|
| |
|
|
| |
llvm-svn: 164673
|
| |
|
|
|
|
|
|
| |
scalar-to-vector conversion that we cannot handle. For instance, when an invalid
constraint is used in an inline asm statement.
<rdar://problem/12284092>
llvm-svn: 164662
|
| |
|
|
|
|
|
|
| |
scalar-to-vector conversion that we cannot handle. For instance, when an invalid
constraint is used in an inline asm statement.
<rdar://problem/12284092>
llvm-svn: 164657
|
| |
|
|
|
|
| |
- Turn on atomic6432.ll and add specific test case as well
llvm-svn: 164616
|
| |
|
|
|
|
| |
caller returns x86_fp80 via st0. rdar://12229511
llvm-svn: 164588
|
| |
|
|
|
|
|
|
|
| |
Even out-of-line jump tables can be in the code section, so mark them
as data-regions for those targets which support the directives.
rdar://12362871&12362974
llvm-svn: 164571
|
| |
|
|
|
|
|
| |
store when handling byval arguments. Thus preventing reordering of the store
with load with post-RA scheduler.
llvm-svn: 164553
|
| |
|
|
| |
llvm-svn: 164472
|
| |
|
|
| |
llvm-svn: 164465
|