| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.
Also comment and sink the include of "Windows.h" in three .inc files to
match the usage in Memory.inc.
llvm-svn: 198685
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ARM backend has been using most of the MachO related subtarget
checks almost interchangeably, and since the only target it's had to
run on has been IOS (which is all three of MachO, Darwin and IOS) it's
worked out OK so far.
But we'd like to support embedded targets under the "*-*-none-macho"
triple, which means everything starts falling apart and inconsistent
behaviours emerge.
This patch should pick a reasonably sensible set of behaviours for the
new triple (and any others that come along, with luck). Some choices
were debatable (notably FP == r7 or r11), but we can revisit those
later when deficiencies become apparent.
llvm-svn: 198617
|
|
|
|
| |
llvm-svn: 198588
|
|
|
|
| |
llvm-svn: 198587
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 0x66 prefix toggles between 16-bit and 32-bit addressing mode.
So in 32-bit mode it is used to switch to 16-bit addressing mode for the
following instruction, while in 16-bit mode it's the other way round — it's
used to switch to 32-bit mode instead.
Thus, emit the 0x66 prefix byte for OpSize only in 32-bit (and 64-bit) mode,
and introduce a new OpSize16 bit which is used in 16-bit mode instead.
This is just the basic infrastructure for that change; a subsequent patch
will add the new OpSize16 bit to the 32-bit instructions that need it.
Patch from David Woodhouse.
llvm-svn: 198586
|
|
|
|
|
|
|
|
|
|
|
| |
This is not really expected to work right yet. Mostly because we will
still emit the OpSize (0x66) prefix in all the wrong places, along with
a number of other corner cases. Those will all be fixed in the subsequent
commits.
Patch from David Woodhouse.
llvm-svn: 198584
|
|
|
|
|
|
|
|
|
| |
Add some tests to validate correct register selection, including a fix
to an existing test which was requiring the *wrong* output.
Patch from David Woodhouse.
llvm-svn: 198566
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch any program that wanted to know the final symbol name of a
GlobalValue had to link with Target.
This patch implements a compromise solution where the mangler uses DataLayout.
This way, any tool that already links with Target (llc, clang) gets the exact
behavior as before and new IR files can be mangled without linking with Target.
With this patch the mangler is constructed with just a DataLayout and DataLayout
is extended to include the information the Mangler needs.
llvm-svn: 198438
|
|
|
|
|
|
|
| |
Printing rounding control.
Enncoding for EVEX_RC (rounding control).
llvm-svn: 198277
|
|
|
|
| |
llvm-svn: 198257
|
|
|
|
| |
llvm-svn: 198241
|
|
|
|
|
|
| |
Reviewed at http://llvm-reviews.chandlerc.com/D2445
llvm-svn: 197826
|
|
|
|
|
|
| |
.weak_def_can_be_hidden was not yet supported by the system assembler
llvm-svn: 196970
|
|
|
|
|
|
|
|
|
|
|
| |
Most users would be surprised if "isCOFF" and "isMachO" were simultaneously
true, unless they'd put the compiler in a box with a gun attached to a photon
detector.
This makes sure precisely one of the three formats is true for any triple and
simplifies some target logic based on that.
llvm-svn: 196934
|
|
|
|
|
|
| |
This matches the behavior of both msvc and mingw.
llvm-svn: 196814
|
|
|
|
|
|
|
| |
This patch tries to avoid unrelated changes other than fixing a few
hyphen-related ambiguities and contractions in nearby lines.
llvm-svn: 196471
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Where it would use a scattered relocation entry but falls back to a
normal relocation entry because the FixupOffset is more than 24-bits.
The bug is in the X86MachObjectWriter::RecordScatteredRelocation() where
it changes reference parameter FixedValue but then returns false to indicate
it did not create a scattered relocation entry. The fix is simply to save the
original value of the parameter FixedValue at the start of the method and
restore it if we are returning false in that case.
rdar://15526046
llvm-svn: 196432
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 196170
|
|
|
|
|
|
|
|
|
| |
CommonTableGen.
add_public_tablegen_target adds *CommonTableGen to LLVM_COMMON_DEPENDS.
LLVM_COMMON_DEPENDS affects add_llvm_library (and other add_target stuff) within its scope.
llvm-svn: 195927
|
|
|
|
| |
llvm-svn: 195926
|
|
|
|
|
|
| |
I forgot to commit them. They were staging in my local repo.
llvm-svn: 195924
|
|
|
|
|
|
| |
Thanks to Roman Divacky for the suggestion.
llvm-svn: 195684
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Mikulas Patocka. I added the test. I checked that for cpu names that
gas knows about, it also doesn't generate nopl.
The modified cpus:
i686 - there are i686-class CPUs that don't have nopl: Via c3, Transmeta
Crusoe, Microsoft VirtualBox - see
https://bbs.archlinux.org/viewtopic.php?pid=775414
k6, k6-2, k6-3, winchip-c6, winchip2 - these are 586-class CPUs
via c3 c3-2 - see https://bugs.archlinux.org/task/19733 as a proof that
Via c3 and c3-Nehemiah don't have nopl
llvm-svn: 195679
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file. The memory leaks in this version have been fixed. Thanks
Alexey for pointing them out.
Differential Revision: http://llvm-reviews.chandlerc.com/D2068
Reviewed by Andy
llvm-svn: 195064
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change is incorrect. If you delete virtual destructor of both a base class
and a subclass, then the following code:
Base *foo = new Child();
delete foo;
will not cause the destructor for members of Child class. As a result, I observe
plently of memory leaks. Notable examples I investigated are:
ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl.
llvm-svn: 194997
|
|
|
|
| |
llvm-svn: 194906
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file.
Differential Revision: http://llvm-reviews.chandlerc.com/D2068
Reviewed by Andy
llvm-svn: 194865
|
|
|
|
|
|
|
|
|
|
| |
On darwin, when trying to create compact unwind info, a .cfi_cfa_def
directive would case an llvm_unreachable() to be hit. Back off when we
see this directive and generate the regular DWARF style eh_frame.
rdar://15406518
llvm-svn: 194285
|
|
|
|
|
|
| |
currently supported in the ELF object writer, along with a simple test case.
llvm-svn: 193709
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is another (final?) stab at making us able to parse our own asm output
on Windows.
Symbols on Windows often contain @'s and ?'s in their names. Our asm parser
didn't like this. ?'s were not allowed, and @'s were intepreted as trying to
reference PLT/GOT/etc.
We can't just add quotes around the bad names, since e.g. for MinGW, we use gas
to assemble, and it doesn't like quotes in some places (notably in .def
directives).
This commit makes us allow ?'s in symbol names, and @'s in symbol names for MS
assembly.
Differential Revision: http://llvm-reviews.chandlerc.com/D1978
llvm-svn: 193000
|
|
|
|
|
|
| |
We had a MCAsmInfoCOFF, but no common class for all the ELF MCAsmInfos before.
llvm-svn: 192760
|
|
|
|
|
|
|
|
| |
No functionality change, but exposes the API so that codegen can use it too.
Patch by Katya Romanova.
llvm-svn: 192757
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes an old FIXME by creating a MCTargetStreamer interface
and moving the target specific functions for ARM, Mips and PPC to it.
The ARM streamer is still declared in a common place because it is
used from lib/CodeGen/ARMException.cpp, but the Mips and PPC are
completely hidden in the corresponding Target directories.
I will send an email to llvmdev with instructions on how to use this.
llvm-svn: 192181
|
|
|
|
|
|
| |
cases from switch.
llvm-svn: 191632
|
|
|
|
| |
llvm-svn: 191630
|
|
|
|
|
|
| |
Phabricator code review is located here: http://llvm-reviews.chandlerc.com/D1750
llvm-svn: 191539
|
|
|
|
| |
llvm-svn: 191362
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
LLVM would crash when trying to come up with a relocation type for
assembly like:
movabsq $V@TPOFF, %rax
Instead, we say the relocation type is R_X86_64_TPOFF64.
Fixes PR17274.
Reviewers: dblaikie, nrieck, rafael
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1717
llvm-svn: 191163
|
|
|
|
| |
llvm-svn: 190551
|
|
|
|
| |
llvm-svn: 190547
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to generate the compact unwind encoding from the machine
instructions. However, this had the problem that if the user used `-save-temps'
or compiled their hand-written `.s' file (with CFI directives), we wouldn't
generate the compact unwind encoding.
Move the algorithm that generates the compact unwind encoding into the
MCAsmBackend. This way we can generate the encoding whether the code is from a
`.ll' or `.s' file.
<rdar://problem/13623355>
llvm-svn: 190290
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expression uses an assembler temporary symbol from an assignment. In this case
the symbol does not have a fragment so the use of getFragment() would be NULL
and caused a crash. In the case of an assembler temporary symbol we want to use
the AliasedSymbol (if any) which will create a local relocation entry, but if
it is not an assembler temporary symbol then let it use that symbol with an
external relocation entry.
rdar://9356266
llvm-svn: 190096
|
|
|
|
|
|
|
|
|
| |
Previously, the clang crash handling code would kick in and give a crash
report for these, even though they're not that sort of error.
rdar://14882264
llvm-svn: 189878
|
|
|
|
| |
llvm-svn: 189728
|
|
|
|
|
|
|
|
|
|
|
|
| |
32-bit absolute addressing in instructions likei this:
mov $_f, %rsi
which is not supported in 64-bit mode.
rdar://8827134
llvm-svn: 189543
|
|
|
|
|
|
| |
in use supports it.
llvm-svn: 189439
|
|
|
|
|
|
|
|
|
| |
Object/MachOFormat.h over to Support/MachO.h."
This reverts commits r189319 and r189315. r189315 broke some tests on what I
believe are big-endian platforms.
llvm-svn: 189321
|
|
|
|
| |
llvm-svn: 189315
|
|
|
|
| |
llvm-svn: 189005
|
|
|
|
|
|
| |
MCJIT code where CurOp was being incremented even if the operand it was pointing at wasn't used. Maybe only matters if there are any EVEX_K instructions that aren't VEX_4V.
llvm-svn: 188868
|