| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 168597
|
|
|
|
|
|
|
|
| |
MachineInstrBuilder.
Simplify some repetitive code with it. No functionality change.
llvm-svn: 168587
|
|
|
|
|
|
|
|
|
|
| |
- MBB address is only valid as an immediate value in Small & Static
code/relocation models. On other models, LEA is needed to load IP address of
the restore MBB.
- A minor fix of MBB in MC lowering is added as well to enable target
relocation flag being propagated into MC.
llvm-svn: 166084
|
|
|
|
|
|
| |
needed outside.
llvm-svn: 166014
|
|
|
|
|
|
| |
ExpandPostRAPseudos and mark them as pseudos in the td file.
llvm-svn: 165302
|
|
|
|
| |
llvm-svn: 162740
|
|
|
|
| |
llvm-svn: 162738
|
|
|
|
| |
llvm-svn: 161122
|
|
|
|
|
|
| |
Fixes pr13048.
llvm-svn: 158158
|
|
|
|
|
|
|
|
|
| |
This implements codegen support for accesses to thread-local variables
using the local-dynamic model, and adds a clean-up pass so that the base
address for the TLS block can be re-used between local-dynamic access on
an execution path.
llvm-svn: 157818
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use a dedicated MachO load command to annotate data-in-code regions.
This is the same format the linker produces for final executable images,
allowing consistency of representation and use of introspection tools
for both object and executable files.
Data-in-code regions are annotated via ".data_region"/".end_data_region"
directive pairs, with an optional region type.
data_region_directive := ".data_region" { region_type }
region_type := "jt8" | "jt16" | "jt32" | "jta32"
end_data_region_directive := ".end_data_region"
The previous handling of ARM-style "$d.*" labels was broken and has
been removed. Specifically, it didn't handle ARM vs. Thumb mode when
marking the end of the section.
rdar://11459456
llvm-svn: 157062
|
|
|
|
|
|
|
| |
This fixes a TODO from 2007 :) Previously, LLVM would emit the wrong
code here (see the update to test/CodeGen/X86/tls-pie.ll).
llvm-svn: 156611
|
|
|
|
|
|
| |
some superfluous forward declarations.
llvm-svn: 152997
|
|
|
|
|
|
|
| |
The different calling conventions and call-preserved registers are
represented with regmask operands that are added dynamically.
llvm-svn: 150708
|
|
|
|
|
|
| |
Patch by Kai Nacke!
llvm-svn: 150307
|
|
|
|
| |
llvm-svn: 149809
|
|
|
|
|
|
|
| |
This is similar to implicit register operands. MC doesn't understand
register liveness and call clobbers.
llvm-svn: 148437
|
|
|
|
|
|
| |
ones if AVX2 is enabled. This gives the ExeDepsFix pass a chance to choose FP vs int as appropriate. Also use v8i32 as the type for getZeroVector if AVX2 is enabled. This is consistent with SSE2 using prefering v4i32.
llvm-svn: 148108
|
|
|
|
|
|
|
|
|
| |
Like V_SET0, these instructions are expanded by ExpandPostRA to xorps /
vxorps so they can participate in execution domain swizzling.
This also makes the AVX variants redundant.
llvm-svn: 145440
|
|
|
|
| |
llvm-svn: 145004
|
|
|
|
|
|
|
|
|
|
|
|
| |
MORESTACK_RET_RESTORE_R10; which are lowered to a RET and a RET
followed by a MOV respectively. Having a fake instruction prevents
the verifier from seeing a MachineBasicBlock end with a
non-terminator (MOV). It also prevents the rather eccentric case of a
MachineBasicBlock ending with RET but having successors nevertheless.
Patch by Sanjoy Das.
llvm-svn: 143062
|
|
|
|
|
|
| |
modes. These are used by disassemblers to provide better disassembly, particularly on targets like ARM Thumb that like to intermingle data in the TEXT segment.
llvm-svn: 141135
|
|
|
|
|
|
|
| |
This also makes it possible to reduce the number of pseudo instructions
and get rid of the encoding information.
llvm-svn: 140776
|
|
|
|
|
|
|
|
| |
fix some subtle bugs involving passes which check mayStore()).
This isn't exactly ideal, but it is good enough for the moment.
llvm-svn: 139245
|
|
|
|
|
|
| |
This also fixes PR10452
llvm-svn: 136004
|
|
|
|
|
|
| |
MCTargetDesc to prepare for next round of changes.
llvm-svn: 135219
|
|
|
|
|
|
| |
rdar://problem/8614450
llvm-svn: 131746
|
|
|
|
| |
llvm-svn: 131654
|
|
|
|
|
|
| |
pseudos. rdar://problem/8614450
llvm-svn: 131641
|
|
|
|
| |
llvm-svn: 121415
|
|
|
|
| |
llvm-svn: 120263
|
|
|
|
| |
llvm-svn: 119092
|
|
|
|
|
|
|
| |
since it is trivial and will be shared between ppc and x86.
This substantially simplifies the X86 backend also.
llvm-svn: 119089
|
|
|
|
| |
llvm-svn: 119088
|
|
|
|
| |
llvm-svn: 117378
|
|
|
|
|
|
|
|
|
| |
reapply: reimplement the second half of the or/add optimization. We should now
with no changes. Turns out that one missing "Defs = [EFLAGS]" can upset things
a bit.
llvm-svn: 116040
|
|
|
|
|
|
|
|
| |
"Reimplement (part of) the or -> add optimization. Matching 'or' into 'add'"
With a critical fix: the add pseudos clobber EFLAGS.
llvm-svn: 116039
|
|
|
|
|
|
| |
'add'", which seems to have broken just about everything.
llvm-svn: 116033
|
|
|
|
|
|
| |
which depends on r116007, which I am about to revert.
llvm-svn: 116031
|
|
|
|
|
|
|
|
|
|
| |
only end up emitting LEA instead of OR. If we aren't able to promote
something into an LEA, we should never be emitting it as an ADD.
Add some testcases that we emit "or" in cases where we used to produce
an "add".
llvm-svn: 116026
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is general goodness because it allows ORs to be converted to LEA to avoid
inserting copies. However, this is bad because it makes the generated .s
file less obvious and gives valgrind heartburn (tons of false positives in
bitfield code).
While the general fix should be in valgrind, we can at least try to avoid
emitting ADD instructions that *don't* get promoted to LEA. This is more
work because it requires introducing pseudo instructions to represents
"add that knows the bits are disjoint", but hey, people really love valgrind.
This fixes this testcase:
https://bugs.kde.org/show_bug.cgi?id=242137#c20
the add r/i cases are coming next.
llvm-svn: 116007
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 113409
|
|
|
|
|
|
|
|
| |
- Do not clobber al during variadic calls, this is AMD64 ABI-only feature
- Emit wincall64, where necessary
Patch by Cameron Esfahani!
llvm-svn: 111289
|
|
|
|
| |
llvm-svn: 111182
|
|
|
|
| |
llvm-svn: 110937
|
|
|
|
|
|
|
|
|
| |
term goal here is to be able to match enough of vector_shuffle and build_vector
so all avx intrinsics which aren't mapped to their own built-ins but to
shufflevector calls can be codegen'd. This is the first (baby) step, support
building zeroed vectors.
llvm-svn: 110897
|
|
|
|
| |
llvm-svn: 110359
|
|
|
|
| |
llvm-svn: 109154
|
|
|
|
|
|
|
|
| |
asmprinter or mangler around. This is option #B for killing off
X86InstrInfo::GetInstSizeInBytes. Option #A (killing
"needsexactsize") was sent for consideration to llvmdev.
llvm-svn: 109056
|