| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is now the same as the behaviour of the GNU assembler. This was done
as it is required in order to build the Linux kernel with the integrated
assembler enabled.
Reviewers: dsanders, vkalintiris
Subscribers: dsanders, llvm-commits
Differential Revision: http://reviews.llvm.org/D13594
llvm-svn: 258400
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
There's an overloading of the "movsd" and "cmpsd" instructions, e.g. movsd can be either "Move Data from String to String" or "Move or Merge Scalar Double-Precision Floating-Point Value".
The former should produce warnings when parsing a memory operand that is not ESI/EDI, but the latter should not.
Fixed the code to produce warnings only after making sure we're dealing with the first case.
Expanded the tests of the produced warnings + fixed RUN line of the test so that it would check both stdout and stderr
Differential Revision: http://reviews.llvm.org/D16359
llvm-svn: 258393
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a symbol S shows up in an expression in assembly there are two
possible interpretations
* The expression is referring to the value of S in this file.
* The expression is referring to the value after symbol resolution.
In the first case the assembler can reason about the value and try to
produce a relocation.
In the second case, that is only possible if the symbol cannot be
preempted.
Assemblers are not very consistent about which interpretation gets used.
This changes MC to agree with GAS in the case of an expression of the
form "Sym - WeakSym".
llvm-svn: 258329
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The AArch64 .inst directive was implemented using EmitIntValue, which resulted
in both $x and $d (code and data) mapping symbols being emitted at the same
address. This fixes it to only emit the $x mapping symbol.
EmitIntValue also emits the value in big-endian order when targeting big-endian
systems, but instructions are always emitted in little-endian order for
AArch64.
Differential Revision: http://reviews.llvm.org/D16349
llvm-svn: 258308
|
| |
|
|
|
|
|
| |
This adds rudimentary support for a few relocations that we will use for
the CodeView debug format.
llvm-svn: 258216
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D16297
llvm-svn: 258161
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D16294
llvm-svn: 258144
|
| |
|
|
|
|
|
|
| |
According to x86 spec "xlat m8" is a legal instruction and it is equivalent to "xlatb".
Differential Revision: http://reviews.llvm.org/D15150
llvm-svn: 258135
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following are legal according to X86 spec:
ins mem, DX
outs DX, mem
lods mem
stos mem
scas mem
cmps mem, mem
movs mem, mem
Differential Revision: http://reviews.llvm.org/D14827
llvm-svn: 258132
|
| |
|
|
|
|
|
|
|
| |
When the shift immediate is zero, PKHTB is an alias for PKHBT, but the order of
the input operands needs to be swapped.
Differential Revision: http://reviews.llvm.org/D16288
llvm-svn: 258044
|
| |
|
|
|
|
|
|
|
|
| |
Baseline/Mainline"
This reverts commit r257883.
Somehow this didn't make it into r257916.
llvm-svn: 257919
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
# The first commit's message is:
Revert "[ARM] Add DSP build attribute and extension targeting"
This reverts commit b11cc50c0b4a7c8cdb628abc50b7dc226ff583dc.
# This is the 2nd commit message:
Revert "[ARM] Add new system registers to ARMv8-M Baseline/Mainline"
This reverts commit 837d08454e3e5beb8581951ac26b22fa07df3cd5.
llvm-svn: 257916
|
| |
|
|
| |
llvm-svn: 257885
|
| |
|
|
| |
llvm-svn: 257884
|
| |
|
|
| |
llvm-svn: 257883
|
| |
|
|
| |
llvm-svn: 257882
|
| |
|
|
| |
llvm-svn: 257881
|
| |
|
|
| |
llvm-svn: 257880
|
| |
|
|
| |
llvm-svn: 257879
|
| |
|
|
| |
llvm-svn: 257878
|
| |
|
|
|
|
| |
features
llvm-svn: 257877
|
| |
|
|
|
|
| |
Sorry for forgetting it the first time.
llvm-svn: 257705
|
| |
|
|
|
|
| |
Fixes PR25944.
llvm-svn: 257697
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes three bugs, in all of which state is not or incorrecly reset between
objects (i.e. when reusing the same pass manager to create multiple object
files):
1) AttributeSection needs to be reset to nullptr, because otherwise the backend
will try to emit into the old object file's attribute section causing a
segmentation fault.
2) MappingSymbolCounter needs to be reset, otherwise the second object file
will start where the first one left off.
3) The MCStreamer base class resets the Streamer's e_flags settings. Since
EF_ARM_EABI_VER5 is set on streamer creation, we need to set it again
after the MCStreamer was rest.
Also rename Reset (uppser case) to EHReset to avoid confusion with
reset (lower case).
Reviewers: rengolin
Differential Revision: http://reviews.llvm.org/D15950
llvm-svn: 257473
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It actually takes an offset into the current PC-region.
This fixes the 'expr' command in lldb.
Reviewers: vkalintiris, jaydeep, bhushan
Subscribers: dsanders, llvm-commits
Differential Revision: http://reviews.llvm.org/D16054
llvm-svn: 257339
|
| |
|
|
| |
llvm-svn: 257304
|
| |
|
|
| |
llvm-svn: 257303
|
| |
|
|
|
|
| |
multiclasses. They weren't used and there were extra spaces in the asm string to prepare for the concatenations of the round string that wasn't ever used.
llvm-svn: 257300
|
| |
|
|
|
|
| |
strings.
llvm-svn: 257299
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM_ENABLE_TIMESTAMPS controls if timestamps are embedded into llvm's
binaries. Turning it off is useful for deterministic builds.
r246905 made it so that the define suddenly also controls if the binaries that
the llvm binaries _create_ embed timestamps or not – but this shouldn't be a
configure-time option. r256203/r256204 added a driver option to toggle this on
and off, so this patch now passes this driver option in LLVM_ENABLE_TIMESTAMPS
builds so that if LLVM_ENABLE_TIMESTAMPS is set, the build of LLVM is
deterministic – but the built clang can still write timestamps into other
executables when requested.
This also allows removing some of the test machinery added in r292012 to work
around this problem.
See PR24740 for background.
http://reviews.llvm.org/D15783
llvm-svn: 256958
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There are a number of files in the tree which have been accidentally checked in with DOS line endings. Convert these to native line endings.
There are also a few files which have DOS line endings on purpose, and I have set the svn:eol-style property to 'CRLF' on those.
Reviewers: joerg, aaron.ballman
Subscribers: aaron.ballman, sanjoy, dsanders, llvm-commits
Differential Revision: http://reviews.llvm.org/D15848
llvm-svn: 256707
|
| |
|
|
| |
llvm-svn: 256527
|
| |
|
|
| |
llvm-svn: 256505
|
| |
|
|
|
|
|
|
| |
names. Add a missing encoding to disassembler and assembler.
I believe this also fixes a case where a 64-bit memory form that is documented as being unsupported in 32-bit mode was able to be selected there.
llvm-svn: 256483
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15711
llvm-svn: 256366
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: arsenm
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D15735
llvm-svn: 256360
|
| |
|
|
|
|
|
|
|
| |
MCDwarf emits a canned abbreviation table, but was not emitting proper
forms for DWARF version 4, which is the default after r249655.
Differential Revision: http://reviews.llvm.org/D15732
llvm-svn: 256313
|
| |
|
|
|
|
|
|
|
|
|
| |
InitMCObjectFileInfo was trying to override the triple in awkward ways.
For example, a triple specifying COFF but not Windows was forced as ELF.
This makes it easy for internal invariants to get violated, such as
those which triggered PR25912.
This fixes PR25912.
llvm-svn: 256226
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Today, we always take into account the possibility that object files
produced by MC may be consumed by an incremental linker. This results
in us initialing fields which vary with time (TimeDateStamp) which harms
hermetic builds (e.g. verifying a self-host went well) and produces
sub-optimal code because we cannot assume anything about the relative
position of functions within a section (call sites can get redirected
through incremental linker thunks).
Let's provide an MCTargetOption which controls this behavior so that we
can disable this functionality if we know a-priori that the build will
not rely on /incremental.
llvm-svn: 256203
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These register has different encodings on CI and VI, so we add pseudo
FLAT_SCRACTH registers to be used before MC, and subtarget specific
registers to be used by the MC layer.
Reviewers: arsenm
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D15661
llvm-svn: 256178
|
| |
|
|
|
|
|
|
| |
for EXT and DEXT* instructions
Differential Revision: http://reviews.llvm.org/D15570
llvm-svn: 256152
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Support for COFF timestamps was unintentionally broken in r246905 when
it was conditionally available depending on whether or not LLVM was
configured with LLVM_ENABLE_TIMESTAMPS. However, Config/config.h was
never included which essentially broke the feature. Due to lax testing,
the breakage was never identified until we observed strange failures
during incremental links of Chromium.
This issue is resolved by simply including Config/config.h in
WinCOFFObjectWriter and teaching lit that the MC/COFF/timestamp.s test
is conditionally supported depending on LLVM_ENABLE_TIMESTAMPS. With
this in place, we can strengthen the test to ensure that it will not
accidentally get broken in the future.
This fixes PR25891.
llvm-svn: 256137
|
| |
|
|
| |
llvm-svn: 256025
|
| |
|
|
|
|
|
|
| |
and WRDSP instructions
Differential Revision: http://reviews.llvm.org/D14429
llvm-svn: 255991
|
| |
|
|
|
|
|
|
|
|
| |
These days relocations are created and stored in a deterministic way.
The order they are created is also suitable for the .o file, so we don't
need an explicit sort.
The last remaining exception is MIPS.
llvm-svn: 255902
|
| |
|
|
|
|
| |
This reverts commit r255762.
llvm-svn: 255806
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The SystemZ linkers provide an optimization to transform a general-
or local-dynamic TLS sequence into an initial-exec sequence if possible.
Do do that, the compiler generates a function call to __tls_get_offset,
which is a brasl instruction annotated with *two* relocations:
- a R_390_PLT32DBL to install __tls_get_offset as branch target
- a R_390_TLS_GDCALL / R_390_TLS_LDCALL to inform the linker that
the TLS optimization should be performed if possible
If the optimization is performed, the brasl is replaced by an ld load
instruction.
However, *both* relocs are processed independently by the linker.
Therefore it is crucial that the R_390_PLT32DBL is processed *first*
(installing the branch target for the brasl) and the R_390_TLS_GDCALL
is processed *second* (replacing the whole brasl with an ld).
If the relocs are swapped, the linker will first replace the brasl
with an ld, and *then* install the __tls_get_offset branch target
offset. Since ld has a different layout than brasl, this may even
result in a completely different (or invalid) instruction; in any
case, the resulting code is corrupted.
Unfortunately, the way the MC common code sorts relocations causes
these two to *always* end up the wrong way around, resulting in
wrong code generation by the linker and crashes.
This patch overrides the sortRelocs routine to detect this particular
pair of relocs and enforce the required order.
llvm-svn: 255787
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARMv8.2-A adds 16-bit floating point versions of all existing SIMD
floating-point instructions. This is an optional extension, so all of
these instructions require the FeatureFullFP16 subtarget feature.
Note that VFP without SIMD is not a valid combination for any version of
ARMv8-A, but I have ensured that these instructions all depend on both
FeatureNEON and FeatureFullFP16 for consistency.
Differential Revision: http://reviews.llvm.org/D15039
llvm-svn: 255764
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARMv8.2-A adds 16-bit floating point versions of all existing VFP
floating-point instructions. This is an optional extension, so all of
these instructions require the FeatureFullFP16 subtarget feature.
The assembly for these instructions uses S registers (AArch32 does not
have H registers), but the instructions have ".f16" type specifiers
rather than ".f32" or ".f64". The top 16 bits of each source register
are ignored, and the top 16 bits of the destination register are set to
zero.
These instructions are mostly the same as the 32- and 64-bit versions,
but they use coprocessor 9 rather than 10 and 11.
Two new instructions, VMOVX and VINS, have been added to allow packing
and extracting two 16-bit floats stored in the top and bottom halves of
an S register.
New fixup kinds have been added for the PC-relative load and store
instructions, but no ELF relocations have been added as they have a
range of 512 bytes.
Differential Revision: http://reviews.llvm.org/D15038
llvm-svn: 255762
|
| |
|
|
|
|
|
|
|
| |
Prior to this patch, we would wrongly stick to the variant with imm8 encoding
even when the relocation could not fit that size.
rdar://problem/23785506
llvm-svn: 255583
|