| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
This diff adds support for -remove-section to llvm-strip.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D46567
llvm-svn: 332081
|
|
|
|
|
|
|
|
|
| |
Verify that the input binary is not getting modified
and add an invocation which uses -remove-section instead of -R.
Test plan: make check-all
llvm-svn: 332078
|
|
|
|
|
|
|
|
|
|
| |
Summary: The final -wasm component has been the default for some time now.
Subscribers: jfb, dschuff, jgravelle-google, eraman, aheejin, JDevlieghere, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D46342
llvm-svn: 332007
|
|
|
|
| |
llvm-svn: 332002
|
|
|
|
|
|
|
|
|
|
|
| |
This diff slightly reorganizes the tests and improves
the test coverage of help messages / error reports.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D46589
llvm-svn: 331993
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewed by: dblaikie, JDevlieghere, espindola
Differential Revision: https://reviews.llvm.org/D44560
Summary:
The .debug_line parser previously reported errors by printing to stderr and
return false. This is not particularly helpful for clients of the library code,
as it prevents them from handling the errors in a manner based on the calling
context. This change switches to using llvm::Error and callbacks to indicate
what problems were detected during parsing, and has updated clients to handle
the errors in a location-specific manner. In general, this means that they
continue to do the same thing to external users. Below, I have outlined what
the known behaviour changes are, relating to this change.
There are two levels of "errors" in the new error mechanism, to broadly
distinguish between different fail states of the parser, since not every
failure will prevent parsing of the unit, or of subsequent unit. Malformed
table errors that prevent reading the remainder of the table (reported by
returning them) and other minor issues representing problems with parsing that
do not prevent attempting to continue reading the table (reported by calling a
specified callback funciton). The only example of this currently is when the
last sequence of a unit is unterminated. However, I think it would be good to
change the handling of unrecognised opcodes to report as minor issues as well,
rather than just printing to the stream if --verbose is used (this would be a
subsequent change however).
I have substantially extended the DwarfGenerator to be able to handle
custom-crafted .debug_line sections, allowing for comprehensive unit-testing
of the parser code. For now, I am just adding unit tests to cover the basic
error reporting, and positive cases, and do not currently intend to test every
part of the parser, although the framework should be sufficient to do so at a
later point.
Known behaviour changes:
- The dump function in DWARFContext now does not attempt to read subsequent
tables when searching for a specific offset, if the unit length field of a
table before the specified offset is a reserved value.
- getOrParseLineTable now returns a useful Error if an invalid offset is
encountered, rather than simply a nullptr.
- The parse functions no longer use `WithColor::warning` directly to report
errors, allowing LLD to call its own warning function.
- The existing parse error messages have been updated to not specifically
include "warning" in their message, allowing consumers to determine what
severity the problem is.
- If the line table version field appears to have a value less than 2, an
informative error is returned, instead of just false.
- If the line table unit length field uses a reserved value, an informative
error is returned, instead of just false.
- Dumping of .debug_line.dwo sections is now implemented the same as regular
.debug_line sections.
- Verbose dumping of .debug_line[.dwo] sections now prints the prologue, if
there is a prologue error, just like non-verbose dumping.
As a helper for the generator code, I have re-added emitInt64 to the
AsmPrinter code. This previously existed, but was removed way back in r100296,
presumably because it was dead at the time.
This change also requires a change to LLD, which will be committed separately.
llvm-svn: 331971
|
|
|
|
|
|
| |
The test needed to check for the optional executable extension (llvm-objcopy.EXE).
llvm-svn: 331952
|
|
|
|
| |
llvm-svn: 331924
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When preprocessing resource scripts (which can easily be done outside
of llvm-rc), included headers can leave behind C declarations (despite
preprocessing with -DRC_INVOKED), that can't be parsed by a resource
compiler.
This is handled in all of rc.exe, by parsing the preprocessor output
line markers and ignoring content from files named *.h and *.c,
documented at [1].
In addition to this filtering, strip out any other preprocessor directive
that is left behind (like pragmas) which also can't be handled by the
tokenizer.
The added test uses both standard #line markers (supported by rc.exe) and
GNU style extended line markers, thus this test doesn't pass with rc.exe,
but passes with GNU windres. (Windres on the other hand doesn't filter
out files named *.c, only *.h.)
Differential Revision: https://reviews.llvm.org/D46579
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa381033(v=vs.85).aspx
llvm-svn: 331903
|
|
|
|
|
|
|
|
|
| |
This is the same as any other user defined resource, but with
a specific allocated resource type number.
Differential Revision: https://reviews.llvm.org/D46636
llvm-svn: 331902
|
|
|
|
|
|
|
|
|
|
|
| |
-1 is commonly used as ID for controls that one don't want to
refer to later. For DIALOG resources, the IDs are 16 bit numbers,
and -1 gets interpreted as UINT32_MAX earlier, which then later is
too large to write into a uint16_t.
Differential Revision: https://reviews.llvm.org/D46506
llvm-svn: 331901
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new verifier check has found an error in the
debug-names-name-collisions.ll test on the PS4 bot:
error: Name Index @ 0x0: Entry @ 0xdc: mismatched Name of DIE @ 0x23: index - _ZN3foo3fooE; debug_info - foo.
Reverting while I investigate whether this is a bug in the verifier or
the generator.
This reverts commit r331868.
llvm-svn: 331869
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch implements a check which makes sure all entries required by
the DWARF v5 specification are present in the Name Index. The algorithm
tries to follow the wording of Section 6.1.1.1 of the spec as closely as
possible.
The main deviation from it is that instead of a whitelist-based approach
in the spec "The name index must contain an entry for each debugging
information entry that defines a named subprogram, label, variable,
type, or namespace" I chose a blacklist-based one, where I consider
everything to be "in" and then remove the entries that don't make sense.
I did this because it has more potential for catching interesting cases
and the above is a bit vague (it uses plain words like "variable" and
"subprogram", but the rest of the section speaks about specific TAGs).
This approach has raised some interesting questions, the main one being
whether enumerator values should be indexed. The consensus seems to be
that they should, although it does not follow from section 6.1.1.1.
For the time being I made the verifier ignore these, as LLVM does not do
this yet, and I wanted to get a clean run when verifying generated debug
info.
Another interesting case was the DW_TAG_imported_declaration. It was not
immediately clear to me whether this should go in or not, but currently
it is not indexed, and (unlike the enumerators) in does not seem to cause
problems for LLDB, so I've also ignored it.
Reviewers: JDevlieghere, aprantl, dblaikie
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D46583
llvm-svn: 331868
|
|
|
|
|
|
|
|
| |
MOVNTPD/MOVNTPS should be WriteFStore
Standardized BDW/HSW/SKL/SKX WriteFStore/WriteVecStore - fixes some missed instregex patterns. (V)MASKMOVDQU was already using the default, its costs gets increased but is still nowhere near the real cost of that nasty instruction....
llvm-svn: 331864
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The operator == used for exporting a function with a different
name in the DLL compared to the name in the import library
(which is useful for adding linker level aliases for function
in the import library) is a feature distinct and different from
the operator = used for exporting a function with a different
name (both in import library and DLL) than in the implementation
producing the DLL.
When creating an import library using dlltool, from a def file that
contains forwards (Func = OtherDll.Func), this shouldn't affect the
produced import library, which should still behave just as if it
was a normal exported function.
This clears a lot of confusion and subtle misunderstandings, and
avoids a parameter that was used to avoid creating weak aliases
when invoked from lld. (This parameter was added previously due to
the existing conflation of the two features.)
Differential Revision: https://reviews.llvm.org/D46245
llvm-svn: 331859
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to set breakpoints on labels and list source code around
labels, we need collect debug information for labels, i.e., label
name, the function label belong, line number in the file, and the
address label located. In order to keep these information in LLVM
IR and to allow backend to generate debug information correctly.
We create a new kind of metadata for labels, DILabel. The format
of DILabel is
!DILabel(scope: !1, name: "foo", file: !2, line: 3)
We hope to keep debug information as much as possible even the
code is optimized. So, we create a new kind of intrinsic for label
metadata to avoid the metadata is eliminated with basic block.
The intrinsic will keep existing if we keep it from optimized out.
The format of the intrinsic is
llvm.dbg.label(metadata !1)
It has only one argument, that is the DILabel metadata. The
intrinsic will follow the label immediately. Backend could get the
label metadata through the intrinsic's parameter.
We also create DIBuilder API for labels to be used by Frontend.
Frontend could use createLabel() to allocate DILabel objects, and use
insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR.
Differential Revision: https://reviews.llvm.org/D45024
Patch by Hsiangkai Wang.
llvm-svn: 331841
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D46507
llvm-svn: 331808
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Don't skip functions with the same name but from different files.
That change makes it possible to generate code coverage reports from
different binaries compiled from different sources even if there are functions
with non-unique names. Without that change, code coverage for such functions is
missing except of the first function processed.
Reviewers: vsk, morehouse
Reviewed By: vsk
Subscribers: llvm-commits, kcc
Differential Revision: https://reviews.llvm.org/D46478
llvm-svn: 331801
|
|
|
|
|
|
|
|
|
|
| |
Set the exit code to 1 if no arguments are specified.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D46547
llvm-svn: 331776
|
|
|
|
|
|
|
| |
This fixes a couple of BtVer2 missing instructions that weren't been handled in the override.
NOTE: There are still a lot of overrides that still need cleaning up!
llvm-svn: 331770
|
|
|
|
| |
llvm-svn: 331769
|
|
|
|
|
|
|
| |
I've created the necessary classes but there are still a lot of overrides that need cleaning up.
NOTE: The Znver1 model was missing some div/idiv variants in the instregex patterns and wasn't setting the resource cycles at all in the overrides.
llvm-svn: 331767
|
|
|
|
| |
llvm-svn: 331765
|
|
|
|
|
|
|
|
|
|
|
|
| |
Regardless of what docs may say, existing resource files in the
wild can use this syntax.
Rename a file used in an existing test, to make it usable for unquoted
paths.
Differential Revision: https://reviews.llvm.org/D46511
llvm-svn: 331747
|
|
|
|
| |
llvm-svn: 331678
|
|
|
|
|
|
|
|
| |
Split to support single/double for scalar, XMM and YMM/ZMM instructions - removing InstrRW overrides for these instructions.
Fixes Atom ADDSUBPD instruction and reclassifies VFPCLASS as WriteFCmp which is closer in behaviour.
llvm-svn: 331672
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D46509
llvm-svn: 331670
|
|
|
|
|
|
|
|
|
| |
This form is even used in one of the examples at
https://msdn.microsoft.com/en-us/library/windows/desktop/aa381050(v=vs.85).aspx.
Differential Revision: https://reviews.llvm.org/D46508
llvm-svn: 331669
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Normally when writing something that requires padding, we first
measure the length of the written payload data, then write
padding if necessary.
For a recursive structure like versioninfo, this means that the
padding is excluded from the size of the inner element, but
included in the size of the enclosing block.
Rc.exe excludes the final padding (but not the padding of earlier
children) from all levels of the hierarchy.
To achieve this, don't pad after each block or value, but only
before starting the next one. We still pad after completing the
toplevel versioninfo resource, so this won't affect other resource
types.
Differential Revision: https://reviews.llvm.org/D46510
llvm-svn: 331668
|
|
|
|
|
|
|
|
|
|
|
|
| |
llvm-strip is supposed to be a drop-in replacement for binutils strip.
To start the ball rolling this diff adds the initial bits for llvm-strip,
more features will be added incrementally over time.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D46407
llvm-svn: 331663
|
|
|
|
|
|
|
|
| |
These are more like cross-lane shuffles than regular shuffles - we already do this for AVX512 equivalents.
Differential Revision: https://reviews.llvm.org/D46229
llvm-svn: 331659
|
|
|
|
|
|
| |
Fixes x87 schedules to more closely match Agner - AMD doesn't tend to "special case" x87 instructions as much as Intel.
llvm-svn: 331645
|
|
|
|
|
|
|
|
| |
and YMM/ZMM instructions.
This removes all InstrRW overrides for these instructions - some x87 overrides remain but most use default (and realistic) values.
llvm-svn: 331643
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WriteFRcp/WriteFRsqrt are split to support scalar, XMM and YMM/ZMM instructions.
WriteFSqrt is split into single/double/long-double sizes and scalar, XMM, YMM and ZMM instructions.
This removes all InstrRW overrides for these instructions.
NOTE: There were a couple of typos in the Znver1 model - notably a 1cy throughput for SQRT that is highly unlikely and doesn't tally with Agner.
NOTE: I had to add Agner's numbers for several targets for WriteFSqrt80.
llvm-svn: 331629
|
|
|
|
|
|
| |
Filled in the missing values from Btver2 SoG or Agner
llvm-svn: 331546
|
|
|
|
|
|
|
|
| |
Split off from SchedWriteFAdd for fp rounding/bit-manipulation instructions.
Fixes an issue on btver2 which only had the ymm version using the JSTC pipe instead of JFPA.
llvm-svn: 331515
|
|
|
|
|
|
|
|
| |
Avoids extra entries in the class tables.
Found a typo that missed the MMX_PHSUBSW instruction.
llvm-svn: 331488
|
|
|
|
|
|
|
|
|
|
| |
specified
This matches what rc.exe does if no output is specified.
Differential Revision: https://reviews.llvm.org/D46239
llvm-svn: 331403
|
|
|
|
|
|
|
|
| |
The real cvtres.exe also allows parameters in either form.
Differential Revision: https://reviews.llvm.org/D46358
llvm-svn: 331402
|
|
|
|
| |
llvm-svn: 331400
|
|
|
|
| |
llvm-svn: 331397
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Only support UTF-8 (since LLVM contains UTF-8 parsing support
already, and the code even does that already) and Windows-1252
(where most code points has the same value in unicode). Keep the
existing default as only allowing ASCII input.
Using the option type JoinedOrSeparate, since the real rc.exe
handles options in this form, even if llvm-rc uses Separate for
other similar existing options.
Rename the struct SearchParams to WriterParams since it's now used
for more than just include paths.
Add a missing getResourceTypeName method to the BundleResource class,
to fix error printing from within STRINGTABLE resources (used in
tests).
Differential Revision: https://reviews.llvm.org/D46238
llvm-svn: 331391
|
|
|
|
|
|
| |
The entries were being bound to the wrong class.
llvm-svn: 331388
|
|
|
|
|
|
| |
https://reviews.llvm.org/D46356
llvm-svn: 331356
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D46296
llvm-svn: 331279
|
|
|
|
|
|
|
|
|
|
|
| |
This prevents infinite recursion in DWARFDie::findRecursively for
malformed DWARF where a DIE references itself.
This fixes PR36257.
Differential revision: https://reviews.llvm.org/D43092
llvm-svn: 331200
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes PR37293.
We can have scheduling classes with no write latency entries, that still consume
processor resources. We don't want to treat those instructions as zero-latency
instructions; they still have to be issued to the underlying pipelines, so they
still consume resource cycles.
This is likely to be a regression which I have accidentally introduced at
revision 330807. Now, if an instruction has a non-empty set of write processor
resources, we conservatively treat it as a normal (i.e. non zero-latency)
instruction.
llvm-svn: 331193
|
|
|
|
|
|
| |
Before this change, it wrongly specified -mcpu=slm instead of -mcpu=atom.
llvm-svn: 331170
|
|
|
|
|
|
|
|
|
| |
Added Intel Atom tests to verify that the tool correctly generates instruction
tables even if the CPU is in-order.
Fixes PR37282.
llvm-svn: 331169
|
|
|
|
| |
llvm-svn: 331144
|