| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 201745
|
|
|
|
|
|
|
|
|
|
| |
TargetLoweringBase is implemented in CodeGen, so before this patch we had
a dependency fom Target to CodeGen. This would show up as a link failure of
llvm-stress when building with -DBUILD_SHARED_LIBS=ON.
This fixes pr18900.
llvm-svn: 201711
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r201608 made llvm corretly handle private globals with MachO. r201622 fixed
a bug in it and r201624 and r201625 were changes for using private linkage,
assuming that llvm would do the right thing.
They all got reverted because r201608 introduced a crash in LTO. This patch
includes a fix for that. The issue was that TargetLoweringObjectFile now has
to be initialized before we can mangle names of private globals. This is
trivially true during the normal codegen pipeline (the asm printer does it),
but LTO has to do it manually.
llvm-svn: 201700
|
|
|
|
|
|
|
| |
This causes the LLVMgold plugin to segfault. More information on the
replies to r201608.
llvm-svn: 201669
|
|
|
|
|
|
|
|
|
|
| |
When outputting an object we check its section to find its name, but when
looking for the section with -ffunction-section we look for the symbol name.
Break the loop by requesting a name with the private prefix when constructing
the section name. This matches the behavior before r201608.
llvm-svn: 201622
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The IR
@foo = private constant i32 42
is valid, but before this patch we would produce an invalid MachO from it. It
was invalid because it would use an L label in a section where the liker needs
the labels in order to atomize it.
One way of fixing it would be to just reject this IR in the backend, but that
would not be very front end friendly.
What this patch does is use an 'l' prefix in sections that we know the linker
requires symbols for atomizing them. This allows frontends to just use
private and not worry about which sections they go to or how the linker handles
them.
One small issue with this strategy is that now a symbol name depends on the
section, which is not available before codegen. This is not a problem in
practice. The reason is that it only happens with private linkage, which will
be ignored by the non codegen users (llvm-nm and llvm-ar).
llvm-svn: 201608
|
|
|
|
|
|
| |
This is quiet a bit less confusing now that TargetData was renamed DataLayout.
llvm-svn: 201606
|
|
|
|
|
|
| |
TargetData was renamed DataLayout back in r165242.
llvm-svn: 201581
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
alongside DIEBlock and replace uses accordingly. Use DW_FORM_exprloc
in DWARF4 and later code. Update testcases.
Adding a DIELoc instead of using extra forms inside DIEBlock so
that we can keep location expressions separate from other uses. No
direct use at the moment, however, it's not a lot of code and
using a separately named class keeps it somewhat more obvious
what's going on in various locations.
llvm-svn: 201481
|
|
|
|
|
|
|
|
|
|
|
|
| |
This broke in r185459 while TLS support was being generalized to handle
non-symbol TLS representations.
I thought about/tried having an enum rather than a bool to track the
TLS-ness of the address table entry, but namespaces and naming seemed
more hassle than it was worth for only one caller that needed to specify
this.
llvm-svn: 201469
|
|
|
|
| |
llvm-svn: 201467
|
|
|
|
|
|
|
|
|
| |
Type units will share the statement list of their defining compile unit.
This is a tradeoff that reduces .o debug info size at the cost of some
linked debug info size (since the contents of those string tables won't
be deduplicated along with the type unit) which seems right for now.
llvm-svn: 201445
|
|
|
|
|
|
|
| |
These types have an out of line virtual function each (emitHeader at
least) so they won't have weak vtables - no need for more than that.
llvm-svn: 201444
|
|
|
|
|
|
| |
-Wunused-member-variable
llvm-svn: 201442
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fission and non-fission cases
This probably also addresses the FIXME in the fission case regarding
multiple compile units, though I haven't tested that.
This code still confuses me (the literal zero offset makes little sense,
the limitations surrounding asm output I'm not sure about either - but
perhaps we should just always emit one line table? Or should we not rely
on .loc/.file even in assembly so we can produce the same output between
asm and object output?) but this maintains the existing functionality.
llvm-svn: 201441
|
|
|
|
| |
llvm-svn: 201433
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when it's unneeded
Recommitting r201380 (reverted in r201389)
Recommitting r201351 and r201355 (reverted in r201351 and r201355)
We weren't emitting the an empty (header only) line table when the line
table was empty - this made the DWARF invalid (the compile unit would
point to the zero-size debug_lines section where there should've been an
empty line table but there was nothing at all). Fix that, and as a
consequence this works around/addresses PR18809.
Also, we emit a non-empty line table to workaround a darwin linker bug,
so XFAILing on darwin too.
Also, mark the test as 'REQUIRES: object-emission' because it does.
llvm-svn: 201429
|
|
|
|
|
|
|
|
| |
for ARM/Thumb functions.
Patch by Keith Walker!
llvm-svn: 201423
|
|
|
|
|
|
|
|
| |
file list when it's unneeded"
This reverts commit r201380 for now while we investigate.
llvm-svn: 201389
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when it's unneeded
Recommitting r201351 and r201355 (reverted in r201351 and r201355)
We weren't emitting the an empty (header only) line table when the line
table was empty - this made the DWARF invalid (the compile unit would
point to the zero-size debug_lines section where there should've been an
empty line table but there was nothing at all). Fix that, and as a
consequence this works around/addresses PR18809.
llvm-svn: 201380
|
|
|
|
|
|
|
| |
option to enable again that will be matched with a commit to enable
in clang.
llvm-svn: 201378
|
|
|
|
| |
llvm-svn: 201365
|
|
|
|
|
|
|
|
| |
in the line table file list when it's unneeded"
It really crashes cygwin's stage2 configure with "clang -g".
llvm-svn: 201351
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
hasRawTextSupport() call
Summary:
AsmPrinter::EmitInlineAsm() will no longer use the EmitRawText() call for
targets with mature MC support. Such targets will always parse the inline
assembly (even when emitting assembly). Targets without mature MC support
continue to use EmitRawText() for assembly output.
The hasRawTextSupport() check in AsmPrinter::EmitInlineAsm() has been replaced
with MCAsmInfo::UseIntegratedAs which when true, causes the integrated assembler
to parse inline assembly (even when emitting assembly output). UseIntegratedAs
is set to true for targets that consider any failure to parse valid assembly
to be a bug. Target specific subclasses generally enable the integrated
assembler in their constructor. The default value can be overridden with
-no-integrated-as.
All tests that rely on inline assembly supporting invalid assembly (for example,
those that use mnemonics such as 'foo' or 'hello world') have been updated to
disable the integrated assembler.
Changes since review (and last commit attempt):
- Fixed test failures that were missed due to configuration of local build.
(fixes crash.ll and a couple others).
- Fixed tests that happened to pass because the local build was on X86
(should fix 2007-12-17-InvokeAsm.ll)
- mature-mc-support.ll's should no longer require all targets to be compiled.
(should fix ARM and PPC buildbots)
- Object output (-filetype=obj and similar) now forces the integrated assembler
to be enabled regardless of default setting or -no-integrated-as.
(should fix SystemZ buildbots)
Reviewers: rafael
Reviewed By: rafael
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2686
llvm-svn: 201333
|
|
|
|
|
|
| |
condition at the call site.
llvm-svn: 201296
|
|
|
|
|
|
|
|
|
|
|
| |
This fix checks the original LLVM IR node to identify opaque constants by
looking for the bitcast-constant pattern. Originally we looked at the generated
SDNode, but this might lead to incorrect results. The SDNode could have been
generated by an constant expression that was folded to a constant.
This fixes <rdar://problem/16050719>
llvm-svn: 201291
|
|
|
|
| |
llvm-svn: 201265
|
|
|
|
| |
llvm-svn: 201264
|
|
|
|
|
|
|
|
|
|
| |
We are now no longer relying on the target-specific call lowering implementation
to lower a stackmap intrinsic call. Instead we perform the call lowering in a
target-independent way directly in the stackmap lowering code. This simplifies
the code and removes the need to fixup the code after the target-specific call
lowering.
llvm-svn: 201263
|
|
|
|
|
|
|
|
|
|
|
| |
documenation)
The ID type for the stackmap and patchpoint intrinsics are in both cases i64.
This fixes an zero extend in the SelectionDAGBuilder that still used i32. This
also updates the target independent instructions STACKMAP and PATCHPOINT to use
the correct type.
llvm-svn: 201262
|
|
|
|
|
|
| |
rdar://problem/16015314
llvm-svn: 201253
|
|
|
|
|
|
|
|
| |
preserve branch probability information.
<rdar://problem/15893208>
llvm-svn: 201245
|
|
|
|
|
|
|
|
| |
AsmPrinter::EmitInlineAsm() and remove hasRawTextSupport() call
It introduced multiple test failures in the buildbots.
llvm-svn: 201241
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
hasRawTextSupport() call
Summary:
AsmPrinter::EmitInlineAsm() will no longer use the EmitRawText() call for targets with mature MC support. Such targets will always parse the inline assembly (even when emitting assembly). Targets without mature MC support continue to use EmitRawText() for assembly output.
The hasRawTextSupport() check in AsmPrinter::EmitInlineAsm() has been replaced with MCAsmInfo::UseIntegratedAs which when true, causes the integrated assembler to parse inline assembly (even when emitting assembly output). UseIntegratedAs is set to true for targets that consider any failure to parse valid assembly to be a bug. Target specific subclasses generally enable the integrated assembler in their constructor. The default value can be overridden with -no-integrated-as.
All tests that rely on inline assembly supporting invalid assembly (for example, those that use mnemonics such as 'foo' or 'hello world') have been updated to disable the integrated assembler.
Reviewers: rafael
Reviewed By: rafael
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2686
llvm-svn: 201237
|
|
|
|
|
|
|
|
|
|
| |
file_names table
There's still one piece missing here, which is adding the
DW_AT_stmt_list to the type unit that refer's to the compile unit's line
table. Working on that.
llvm-svn: 201198
|
|
|
|
| |
llvm-svn: 201197
|
|
|
|
|
|
|
|
|
| |
DwarfTypeUnit.
Type units need to insert their file strings into the compile unit's
line/file table. This is preliminary work to that end.
llvm-svn: 201196
|
|
|
|
|
|
|
|
| |
This is preliminary work to fix type unit file strings so they appear in
their originating CU's line table - but it's also just good/simple
cleanup, so I'm committing it ahead of time.
llvm-svn: 201195
|
|
|
|
|
|
|
|
| |
We used to be pretty vague about what debug entities were what, with
many conditionals to silently drop/skip/accept things. These don't seem
to be relevant anymore.
llvm-svn: 201194
|
|
|
|
|
|
|
|
|
|
|
|
| |
Debug info: Emit values in subregisters that do not have a separate
DWARF register number by emitting a super-register + DW_OP_bit_piece.
This is necessary because on x86_64, there are no DWARF register numbers
for i386-style subregisters.
Fixes a bunch of FIXMEs.
rdar://problem/16015314
llvm-svn: 201190
|
|
|
|
|
|
| |
This reverts commit r201179 for buildbot breakage.
llvm-svn: 201188
|
|
|
|
|
|
|
|
|
|
| |
when it's unneeded
This comes up in empty files or files containing #file directives that
never reference the actual source file name. Came up in a small test of
line tables I was playing with.
llvm-svn: 201187
|
|
|
|
| |
llvm-svn: 201181
|
|
|
|
|
|
|
|
|
|
|
| |
DWARF register number by emitting a super-register + DW_OP_bit_piece.
This is necessary because on x86_64, there are no DWARF register numbers
for i386-style subregisters.
Fixes a bunch of FIXMEs.
rdar://problem/16015314
llvm-svn: 201180
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUILD_VECTOR nodes, e.g.:
(concat_vectors (BUILD_VECTOR a1, a2, a3, a4), (BUILD_VECTOR b1, b2, b3, b4))
->
(BUILD_VECTOR a1, a2, a3, a4, b1, b2, b3, b4)
This fixes an issue with AVX, where a sequence was not recognized as a 256-bit
vbroadcast due to the concat_vectors.
llvm-svn: 201158
|
|
|
|
| |
llvm-svn: 201119
|
|
|
|
| |
llvm-svn: 201115
|
|
|
|
|
|
| |
Thanks to Chandler for the catch.
llvm-svn: 201095
|
|
|
|
|
|
|
|
|
| |
These methods normally call each other and it is really annoying if the
arguments are in different order. The more common rule was that the arguments
specific to call are first (GV, Encoding, Suffix) and the auxiliary objects
(Mang, TM) come after. This patch changes the exceptions.
llvm-svn: 201044
|
|
|
|
| |
llvm-svn: 201043
|