[NFC][TargetParser] Replace uses of llvm/Support/Host.h

The forwarding header is left in place because of its use in
`polly/lib/External/isl/interface/extract_interface.cc`, but I have
added a GCC w

[NFC][TargetParser] Replace uses of llvm/Support/Host.h

The forwarding header is left in place because of its use in
`polly/lib/External/isl/interface/extract_interface.cc`, but I have
added a GCC warning about the fact it is deprecated, because it is used
in `isl` from where it is included by Polly.

show more ...

[NFC][TargetParser] Remove llvm/ADT/Triple.h

I also ran `git clang-format` to get the headers in the right order for
the new location, which has changed the order of other headers in two
files.

[unittest][DebugInfo/DWARF] Do not create dwarfgen::Generator if MCAsmBackend is missing

dwarfgen::Generator cannot be created if there is no asm backend for a
target. For example, if the default ta

[unittest][DebugInfo/DWARF] Do not create dwarfgen::Generator if MCAsmBackend is missing

dwarfgen::Generator cannot be created if there is no asm backend for a
target. For example, if the default target triple is nvptx-nvidia-cuda,
some tests fail even after D98400, which added checks for most cases.
This patch extends the approach to the remaining cases.

Differential Revision: https://reviews.llvm.org/D116107

show more ...

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually us

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually use the target, so we might as well move this out of Support.

This allows us to ensure that Support doesn't have includes from MC/*.

Differential Revision: https://reviews.llvm.org/D111454

show more ...

[Test][DebugInfo] Check for backend object emission support.

The XCore backend does not support object emission. Several tests fail for this
reason when XCore is the default target. See staging buil

[Test][DebugInfo] Check for backend object emission support.

The XCore backend does not support object emission. Several tests fail for this
reason when XCore is the default target. See staging buildbot builder:
clang-xcore-ubuntu-20-x64.

So check for backend object emission before running the tests requiring it.

Incorporate isConfigurationSupported functionality in isObjectEmissionSupported,
to avoid calling them both in the same tests.

Differential Revision: https://reviews.llvm.org/D98400

show more ...

Fix DWARF DebugInfo unit test errors when cross-compiling

Summary:
When building with a Default Target set we can experience issues
in the DWARF DebugInfo unit tests because:

They assume we can gen

Fix DWARF DebugInfo unit test errors when cross-compiling

Summary:
When building with a Default Target set we can experience issues
in the DWARF DebugInfo unit tests because:

They assume we can generate object files for the host platform.
Some tests assume the endianess of the target we are generating
DWARF for and the host match.

This patch correct these issues by ensuring the tests which
generate objects in memory are run with respect to
LVM_DEFAULT_TARGET_TRIPLE and it's endianess.

We also make sure we don't use the hosts address size for line test
and split the triple util function in DwarfUtils into a version
that takes an address size and one that doesn't.

See also for discussion:
http://lists.llvm.org/pipermail/llvm-dev/2019-March/131212.html

Patch by: daltenty

Differential Revision: https://reviews.llvm.org/D62084

llvm-svn: 362454

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

IWYU for llvm-config.h in llvm, additions.

See r331124 for how I made a list of files missing the include.
I then ran this Python script:

for f in open('filelist.txt'):
f = f.strip()

IWYU for llvm-config.h in llvm, additions.

See r331124 for how I made a list of files missing the include.
I then ran this Python script:

for f in open('filelist.txt'):
f = f.strip()
fl = open(f).readlines()

found = False
for i in xrange(len(fl)):
p = '#include "llvm/'
if not fl[i].startswith(p):
continue
if fl[i][len(p):] > 'Config':
fl.insert(i, '#include "llvm/Config/llvm-config.h"\n')
found = True
break
if not found:
print 'not found', f
else:
open(f, 'w').write(''.join(fl))

and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p`
and tried to fix include ordering and whatnot.

No intended behavior change.

llvm-svn: 331184

show more ...

[DWARF] Don't attempt to parse line tables at invalid offsets

Whilst working on improvements to the error handling of the debug line
parsing code, I noticed that if an invalid offset were to be spec

[DWARF] Don't attempt to parse line tables at invalid offsets

Whilst working on improvements to the error handling of the debug line
parsing code, I noticed that if an invalid offset were to be specified
in a call to getOrParseLineTable(), an entry in the LineTableMap would
still be created, even if the offset was not within the section range.
The immediate parsing attempt afterwards would fail (it would end up
getting a version of 0), and thereafter, any subsequent calls to
getOrParseLineTable or getLineTable would return the default-
constructed, invalid line table. In reality, we shouldn't even attempt
to parse this table, and we should always return a nullptr from these
two functions for this situation.

I have tested this via a unit test, which required some new framework
for unit testing debug line. My plan is to add quite a few more unit
tests for the new error reporting mechanism that will follow shortly,
hence the reason why the supporting code for the tests are written the
way they are - I intend to extend the DwarfGenerator class to support
generating debug line. At that point, I'll make sure that there are a
few positive test cases for this and the parsing code too.

Differential Revision: https://reviews.llvm.org/D44200

Reviewers: JDevlieghere, aprantl
llvm-svn: 326995

show more ...