name might indicate, it is an iterator over the types in an instruction
in the IR.... You see where this is going.
Another step of modularizing the support library.
llvm-svn: 202815
business.
This header includes Function and BasicBlock and directly uses the
interfaces of both classes. It has to do with the IR, it even has that
in the name. =] Put it in the library it belongs to.
This is one step toward making LLVM's Support library survive a C++
modules bootstrap.
llvm-svn: 202814
Since these are primarily useful for deeply embedded targets where code size is
very important, they are each in a separate file making use of infrastructure
in sync-ops.h. This allows a linker to include just the functions that are
actually used.
rdar://problem/14736665
llvm-svn: 202812
a missing include from CLog.h.
CLog.h referenced most of the core libclang types but never directly
included Index.h that provides them. Previously it got lucky and other
headers were always included first but with the sorting it ended up
first in one case and stopped compiling. Adding the Index.h include
fixes it right up.
llvm-svn: 202810
out-of-line so that it can refer to the methods on User. As
a consequence, this removes the need to define one template method if
value_use_iterator in the extremely strange User.h header (!!!).
This makse Use.h slightly less peculiar. The only remaining real
peculiarity is the definition of Use::set in Value.h
llvm-svn: 202805
inconsistent both with itself and with LLVM at large with formatting.
The *s were on the wrong side, the indent was off, etc etc. This is much
cleaner.
Also, go clang-format laying out the array of tags in nice columns.
llvm-svn: 202799
Patch by Brad King.
Our add_sanitizer_rt_symbols macro reads the LOCATION property of a
library to compute the location of the "lib<name>.a.syms" file to
generate next to the corresponding "lib<name>.a" library file. CMake
3.0 introduces policy CMP0026 to disallow reading of the LOCATION target
property from non-imported targets in favor of the more powerful
$<TARGET_FILE> generator expression.
Teach add_sanitizer_rt_symbols to use the $<TARGET_FILE> generator
expression to compute the location of the symbols file to generate
with a custom command. CMake 3.0 also adds support for generator
expressions to install(FILES) so use it when available to simplify
installation of the symbols file of the proper configuration.
llvm-svn: 202797
Patch by Brad King.
When using a multi-config generator with CMake, such as for VS or Xcode,
the LOCATION target property value contains a placeholder such as
"$(Configuration)" that is meant for substitution by the native build
tool. The install(FILES) command does not understand this name and will
not install the symbols file correctly when using these generators.
Teach add_sanitizer_rt_symbols to read the more-specific target property
LOCATION_<CONFIG> that has a per-configuration value and no placeholder.
On single-configuration generators (Makefile, Ninja), CMAKE_BUILD_TYPE
contains the name of the one configuration to be built. On multi-config
generators (VS, Xcode), CMAKE_CONFIGURATION_TYPES contains the list of
possible configurations. In the latter case, loop over the configs and
add a configuration-specific install(FILES) rule for each one.
Place the code block inside an if(TRUE) block so it can be made
conditional in a following change without updating indentation.
llvm-svn: 202796
We wouldn't recognize variable templates as being templates leading us
to leave the template arguments off of the mangled name. This would
allow two unrelated templates to map to the same mangled name.
N.B. While MSVC doesn't support variable templates as of this date,
this mangling is the most likely thing they will choose to use. Their
demangler can successfully demangle our manglings with the template
arguments shown.
llvm-svn: 202789
The following two tests showed up as XFAIL even though they should
always be skipped on Linux, due to the @unittest2.expectedFailure
annotation appearing above the @dsym_test annotation:
TestObjCNewSyntax.ObjCNewSyntaxTestCase.test_expr_with_dsym
TestBlocks.BlocksTestCase.test_expr_with_dsym.
For those two, I simply moved the @dsym_test annotation to the top so
that it would be marked for skip ahead of being marked for XFAIL.
TestObjCNewSyntax.ObjCNewSyntaxTestCase.test_expr_with_dwarf I marked
as @skipIfLinux since my understanding is that isn't a valid test to
run on Linux. So rather than categorize as a fail (i.e. something
wrong to be fixed), just skip it. (My recent changes to Linux tests
have been following that model: if it could never work, skip; if it's
broken, mark XFAIL so we can easily track, fix, notice the fix and
adjust accordingly).
TestDeadStrip.DeadStripTestCase.test_with_dwarf I had previously
marked as XFAIL but this would never work on Linux with the current
linker AFAICT. Marked it as skip.
llvm-svn: 202788
The original code does not work correctly on executable files because the
code is written in such a way that only object files are assumed to be given
to llvm-objdump.
Contents of RuntimeFunction are different between executables and objects. In
executables, fields in RuntimeFunction have actual addresses to unwind info
structures. On the other hand, in object files, the fields have zero value,
but instead there are relocations pointing to the fields, so that Linker will
fill them at link-time.
So, when we are reading an object file, we need to use relocation info to
find the location of unwind info. When executable, we should just look at the
values in RuntimeFunction.
llvm-svn: 202785
We should only have this optimization fire when the explicit
instantiation definition would cause at least one member function to be
emitted, thus ensuring that even a compiler not performing this
optimization would still emit the full type information elsewhere.
But we should also pessimize output still by always emitting the
definition when the explicit instantiation definition appears so that at
some point in the future we can depend on that information even when no
code had to be emitted in that TU. (this shouldn't happen very often,
since people mostly use explicit spec decl/defs to reduce code size -
but perhaps one day they could use it to explicitly reduce debug info
size too)
This was worth about 2% for Clang and LLVM - so not a huge win, but a
win. It looks really great for simple STL programs (include <string> and
just declare a string - 14k -> 1.4k of .dwo)
llvm-svn: 202769
for the Cortex-A53 subtarget in the AArch64 backend.
This patch lays the ground work to annotate each AArch64 instruction
(no NEON yet) with a list of SchedReadWrite types. The patch also
provides the Cortex-A53 processor resources, maps those the the default
SchedReadWrites, and provides basic latency. NEON support will be added
in a subsequent patch with proper forwarding logic.
Verification was done by setting the pre-RA scheduler to linearize to
better gauge the effect of the MIScheduler. Even without modeling the
forward logic, the results show a modest improvement for Cortex-A53.
Reviewers: apazos, mcrosier, atrick
Patch by Dave Estes <cestes@codeaurora.org>!
llvm-svn: 202767
Chandler Carruth