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>!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203125 91177308-0d34-0410-b5e6-96231b3b80d8
Just the simple cases for now. There were a few knock-on changes of
MachineBasicBlock *s to MachineBasicBlock &s. No functional change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203105 91177308-0d34-0410-b5e6-96231b3b80d8
This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203083 91177308-0d34-0410-b5e6-96231b3b80d8
This is consistent with GDB ToT and reduces the number of relocations in
(type and compile) units, substantially reducing relocations and debug
size in fission + type units builds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203082 91177308-0d34-0410-b5e6-96231b3b80d8
selfhost.
The 'Core.h' C-API header is part of the IR LLVM library. (One might
even argue it should be called IR.h, but that's a separate point.) We
can't include it into a Support header without violating the layering,
and in a way that breaks modules. MemoryBuffer's opaque C type was being
defined in the Core.h C-API header despite being in the Support library,
and thus we ended up with this weird issue.
It turns out that there were other constructs from the Support library
in the Core.h header. This patch lifts all of them into Support.h and
then includes that into Core.h.
The only possible fallout is if someone was including Support.h and
relying on Core.h to be visible for their own uses. Considering the
narrow interface actually provided by the C-API for the Support library,
this seems a very, very unlikely mistake.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203071 91177308-0d34-0410-b5e6-96231b3b80d8
implementation already lived.
After this commit, the only IR-library headers in include/llvm/* are
ones related to the legacy pass infrastructure that I'm planning to
leave there until the new one is farther along.
The only other headers at the top level are linking and initialization
aids that aren't really libraries but just headers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203069 91177308-0d34-0410-b5e6-96231b3b80d8
The global base register cannot be r0 because it might end up as the first
argument to addi or addis. Fixes PR18316.
I don't have a small stable test case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203054 91177308-0d34-0410-b5e6-96231b3b80d8
The iterator is a little complex because we don't want to expose the implementation
details (TrackingVH) of the operand vector to clients.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203053 91177308-0d34-0410-b5e6-96231b3b80d8
pointed to by the attribute, rather than the form as a first
step to determining how to hash the values. No functional change
intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203044 91177308-0d34-0410-b5e6-96231b3b80d8
When copying an i1 value into a GPR for a vaarg call, we need to explicitly
zero-extend the i1 value (otherwise an invalid CRBIT -> GPR copy will be
generated).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203041 91177308-0d34-0410-b5e6-96231b3b80d8
are operations that do not access memory but may be sensitive
to floating-point environment changes. LLVM does not attempt
to model FP environment changes, so this was unnecessarily conservative
and was getting on the way of some optimizations, in particular
SLP vectorization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203037 91177308-0d34-0410-b5e6-96231b3b80d8
This works by moving the existing code into the DIEValue hierarchy
and using the DwarfDebug pointer off of the AsmPrinter to access
any global information we need.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203033 91177308-0d34-0410-b5e6-96231b3b80d8
This enables us to figure out where in the debug_loc section our
locations are so that we can eventually hash them. It also helps
remove some special case code in emission. No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203018 91177308-0d34-0410-b5e6-96231b3b80d8
On cores without fpcvt support, we cannot promote int_to_fp i1 operations,
because there is nothing to promote them to. The most straightforward
implementation of this uses a select to choose between the two possible
resulting floating-point values (and that's what is done here).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203015 91177308-0d34-0410-b5e6-96231b3b80d8
Before llvm-mc would print it, but llc was assuming that it would produce
another section changing directive before one was needed. That assumption is
false with inline asm.
Fixes PR19049.
Another option would be to always create the section, but in the asm printer
avoid printing sections changes during initialization. That would work, but
* We do use the fact that llvm-mc prints it in testing. The tests can be changed
if needed.
* A quick poll on IRC suggest that most developers prefer the implicit .text to
be printed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203001 91177308-0d34-0410-b5e6-96231b3b80d8
When using a //net/ path, we were transforming the trailing / into a '.'
when the path was just the root path and we were iterating backwards.
Forwards iteration and other kinds of root path (C:\, /) were already
correct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202999 91177308-0d34-0410-b5e6-96231b3b80d8
