| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
This reverts commit r236340.
llvm-svn: 236359
|
|
|
|
|
|
| |
This reverts commit r236339, it breaks the win32 clang-cl self-host.
llvm-svn: 236340
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This pass is responsible for constructing the EH registration object
that gets linked into fs:00, which is all it does in this change. In the
future, it will also insert stores to update the EH state number.
I considered keeping this functionality in WinEHPrepare, but it's pretty
separable and X86 specific. It has conceptually very little to do with
the task of WinEHPrepare, which is currently outlining. WinEHPrepare is
also in theory useful on ARM, but this logic is pretty x86 specific.
Reviewers: andrew.w.kaylor, majnemer
Differential Revision: http://reviews.llvm.org/D9422
llvm-svn: 236339
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
x86 Windows uses the '_' prefix for all global symbols, and this was
mistakenly being applied to frameescape labels, which are not externally
visible global symbols. They use the private global prefix 'L'.
The *right* way to fix this is probably to stop masquerading this label
as an ExternalSymbol and create a new SDNode type. These labels are not
"external", and we know they will be resolved by assembly time. Having a
custom SDNode type would allow us to do better X86 address mode
matching, so it's probably worth doing eventually.
llvm-svn: 236123
|
|
|
|
|
|
|
| |
It was only used by MachO.
Part of pr19627.
llvm-svn: 235185
|
|
|
|
|
|
| |
The ELF object writer will take advantage of that in the next commit.
llvm-svn: 234950
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is generated using clang-tidy misc-use-override check.
This command was used:
tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \
-checks='-*,misc-use-override' -header-filter='llvm|clang' \
-j=32 -fix -format
http://reviews.llvm.org/D8925
llvm-svn: 234679
|
|
|
|
| |
llvm-svn: 234519
|
|
|
|
| |
llvm-svn: 234506
|
|
|
|
|
|
|
| |
an MCInstPrinter. Update all callers and use where we wanted a Triple
previously.
llvm-svn: 233648
|
|
|
|
| |
llvm-svn: 233614
|
|
|
|
| |
llvm-svn: 233607
|
|
|
|
| |
llvm-svn: 233392
|
|
|
|
|
|
| |
functions from X86 MC layer. They haven't been used since CPU autodetection was removed from X86Subtarget.cpp.
llvm-svn: 233170
|
|
|
|
|
|
|
|
| |
This reverts commit r233055.
It still causes buildbot failures (gcc running out of memory on several platforms, and a self-host failure on arm), although less than the previous time.
llvm-svn: 233068
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, subtarget features were a bitfield with the underlying type being uint64_t.
Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset.
No functional change.
The first time this was committed (r229831), it caused several buildbot failures.
At least some of the ARM ones were due to gcc/binutils issues, and should now be fixed.
Differential Revision: http://reviews.llvm.org/D8542
llvm-svn: 233055
|
|
|
|
|
|
|
|
|
|
| |
Simplify boolean expressions with `true` and `false` with `clang-tidy`
Patch by Richard Thomson.
Differential Revision: http://reviews.llvm.org/D8519
llvm-svn: 233002
|
|
|
|
| |
llvm-svn: 232923
|
|
|
|
|
|
| |
- was reporting 'warning C4715: 'getType32' : not all control paths return a value'
llvm-svn: 232913
|
|
|
|
| |
llvm-svn: 232848
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main differences are:
* Split in 32 and 64 bit functions.
* First switch on the Modifier so that we have only one non fully covered
switch.
* Map the fixup kind first to a x86_64 (or i386) specific enum, to make
it easy to handle cases like X86::reloc_riprel_4byte_movq_load.
* Switch on IsPCRel last, which reduces code duplication.
Fixes pr22308.
llvm-svn: 232837
|
|
|
|
| |
llvm-svn: 232814
|
|
|
|
| |
llvm-svn: 232813
|
|
|
|
| |
llvm-svn: 232811
|
|
|
|
| |
llvm-svn: 232810
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two main advantages to doing this
* Targets that only need to handle one of the formats specially don't have
to worry about the others. For example, x86 now only registers a
constructor for the COFF streamer.
* Changes to the arguments passed to one format constructor will not impact
the other formats.
llvm-svn: 232699
|
|
|
|
| |
llvm-svn: 232688
|
|
|
|
|
|
|
|
| |
We can get there with .code64.
Fixes pr22349.
llvm-svn: 232651
|
|
|
|
| |
llvm-svn: 232429
|
|
|
|
| |
llvm-svn: 232428
|
|
|
|
|
|
|
|
|
| |
uppercase letter
This covers essentially all of llvm's headers and libs. One or two weird
cases I wasn't sure were worth/appropriate to fix.
llvm-svn: 232394
|
|
|
|
|
|
|
| |
update all ports accordingly. Required a couple of small rewrites
in handling subtarget features during creation in PPC.
llvm-svn: 231861
|
|
|
|
|
|
|
| |
Differential Revision: D7990
Reviewed by: rafael, majnemer
llvm-svn: 231216
|
|
|
|
| |
llvm-svn: 229841
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, subtarget features were a bitfield with the underlying type being uint64_t.
Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset.
No functional change.
Differential Revision: http://reviews.llvm.org/D7065
llvm-svn: 229831
|
|
|
|
|
|
| |
NFC. (It seems this code has been copy/pasted around, unfortunately.)
llvm-svn: 229417
|
|
|
|
|
|
| |
requiring the macro. NFC; LLVM edition.
llvm-svn: 229340
|
|
|
|
|
|
| |
encodings linear which can then be used to simplify some other code.
llvm-svn: 229279
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This mostly reverts commit r222062 and replaces it with a new enum. At
some point this enum will grow at least for other MSVC EH personalities.
Also beefs up the way we were sniffing the personality function.
Previously we would emit the Itanium LSDA despite using
__C_specific_handler.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D6987
llvm-svn: 226920
|
|
|
|
|
|
|
|
|
|
|
|
| |
Windows supports a restricted set of relocations (compared to ARM ELF). In some
cases, we may end up generating an unsupported relocation. This can occur with
bad input to the assembler in particular (the frontend should never generate
code that cannot be compiled). Generate an error rather than just aborting.
The change in the API is driven by the desire to provide a slightly more helpful
message for debugging purposes.
llvm-svn: 226779
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fixes are to note that AArch64 has additional restrictions on when local
relocations can be used. In particular, ld64 requires that relocations to
cstring/cfstrings use linker visible symbols.
Original message:
In an assembly expression like
bar:
.long L0 + 1
the intended semantics is that bar will contain a pointer one byte past L0.
In sections that are merged by content (strings, 4 byte constants, etc), a
single position in the section doesn't give the linker enough information.
For example, it would not be able to tell a relocation must point to the
end of a string, since that would look just like the start of the next.
The solution used in ELF to use relocation with symbols if there is a non-zero
addend.
In MachO before this patch we would just keep all symbols in some sections.
This would miss some cases (only cstrings on x86_64 were implemented) and was
inefficient since most relocations have an addend of 0 and can be represented
without the symbol.
This patch implements the non-zero addend logic for MachO too.
llvm-svn: 226503
|
|
|
|
| |
llvm-svn: 226182
|
|
|
|
|
|
| |
This reverts commit r225644 while I debug a regression.
llvm-svn: 226022
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One is that AArch64 has additional restrictions on when local relocations can
be used. We have to take those into consideration when deciding to put a L
symbol in the symbol table or not.
The other is that ld64 requires the relocations to cstring to use linker
visible symbols on AArch64.
Thanks to Michael Zolotukhin for testing this!
Remove doesSectionRequireSymbols.
In an assembly expression like
bar:
.long L0 + 1
the intended semantics is that bar will contain a pointer one byte past L0.
In sections that are merged by content (strings, 4 byte constants, etc), a
single position in the section doesn't give the linker enough information.
For example, it would not be able to tell a relocation must point to the
end of a string, since that would look just like the start of the next.
The solution used in ELF to use relocation with symbols if there is a non-zero
addend.
In MachO before this patch we would just keep all symbols in some sections.
This would miss some cases (only cstrings on x86_64 were implemented) and was
inefficient since most relocations have an addend of 0 and can be represented
without the symbol.
This patch implements the non-zero addend logic for MachO too.
llvm-svn: 225644
|
|
|
|
|
|
|
|
|
|
| |
introduced.
A test case for the bug was already committed in r225385.
Patch by Rafael Espindola.
llvm-svn: 225534
|
|
|
|
|
|
|
|
| |
This is affecting the behavior of some ObjC++ / AArch64 test cases on Darwin.
Reverting to get the bots green while I track down the source of the changed
behavior.
llvm-svn: 225311
|
|
|
|
|
|
| |
I've filed http://llvm.org/PR22100 to track this issue.
llvm-svn: 225228
|
|
|
|
| |
llvm-svn: 225227
|
|
|
|
|
|
| |
incrementing. NFC
llvm-svn: 225156
|
|
|
|
|
|
| |
assignment as the beginning of the function. NFC.
llvm-svn: 225155
|