| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
This reverts commits r203136, r203137, and r203138.
This code doesn't build on Windows. Even on Vista+, Windows requires
elevated privileges to create a symlink. Therefore we can't use
symlinks in the compiler. We'll have to find another approach.
llvm-svn: 203143
|
| |
|
|
|
|
| |
No functional change.
llvm-svn: 203142
|
| |
|
|
|
|
|
|
|
|
|
| |
There was a race where:
- The LockFileManager tries to own the lock file and fails.
- The other owner then releases and removes the lock file.
- The LockFileManager tries to read the owner info from the lock file but fails now.
In such a case have LockFileManager try to get ownership again, instead of error'ing out.
llvm-svn: 203138
|
| |
|
|
|
|
|
|
| |
Hard links do not work on SMB network directories, and it causes us to fail
to build clang module files if the module cache is in such a directory.
rdar://15944959
llvm-svn: 203137
|
| |
|
|
| |
llvm-svn: 203136
|
| |
|
|
|
|
|
| |
This appears to only be working for global loads. Private
and local break for other reasons.
llvm-svn: 203135
|
| |
|
|
| |
llvm-svn: 203134
|
| |
|
|
| |
llvm-svn: 203133
|
| |
|
|
| |
llvm-svn: 203132
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This provides support for CP and DP relative global accesses in inline
asm.
Reviewers: robertlytton
Reviewed By: robertlytton
Differential Revision: http://llvm-reviews.chandlerc.com/D2943
llvm-svn: 203129
|
| |
|
|
| |
llvm-svn: 203127
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 203125
|
| |
|
|
|
|
|
| |
Also fix a couple of cases where "override" was missing. No behavioural
change intended.
llvm-svn: 203110
|
| |
|
|
|
|
| |
No functional change intended.
llvm-svn: 203106
|
| |
|
|
|
|
|
| |
Just the simple cases for now. There were a few knock-on changes of
MachineBasicBlock *s to MachineBasicBlock &s. No functional change intended.
llvm-svn: 203105
|
| |
|
|
|
|
| |
No functional change intended.
llvm-svn: 203103
|
| |
|
|
|
|
|
|
| |
packed instructions, added encoding tests for them.
By Robert Khazanov.
llvm-svn: 203098
|
| |
|
|
| |
llvm-svn: 203096
|
| |
|
|
| |
llvm-svn: 203093
|
| |
|
|
| |
llvm-svn: 203089
|
| |
|
|
| |
llvm-svn: 203086
|
| |
|
|
| |
llvm-svn: 203084
|
| |
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 203083
|
| |
|
|
|
|
|
|
|
|
| |
DW_AT_GNU_pubnames of DW_FORM_flag(_present) rather than sec_offsets to the pubnames/types sections
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.
llvm-svn: 203082
|
| |
|
|
| |
llvm-svn: 203076
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 203071
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 203069
|
| |
|
|
| |
llvm-svn: 203066
|
| |
|
|
|
|
| |
consistent with every other sub-library header in LLVM.
llvm-svn: 203065
|
| |
|
|
|
|
| |
obviously coupled to the IR.
llvm-svn: 203064
|
| |
|
|
|
|
|
|
| |
make it true.
It ought to be possible to make this truly random access if anyone cares enough.
llvm-svn: 203060
|
| |
|
|
|
|
| |
Chandler in review.
llvm-svn: 203058
|
| |
|
|
|
|
| |
emitting pub sections for compile units
llvm-svn: 203057
|
| |
|
|
| |
llvm-svn: 203055
|
| |
|
|
|
|
|
|
|
| |
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.
llvm-svn: 203054
|
| |
|
|
|
|
|
| |
The iterator is a little complex because we don't want to expose the implementation
details (TrackingVH) of the operand vector to clients.
llvm-svn: 203053
|
| |
|
|
|
|
| |
already lives.
llvm-svn: 203046
|
| |
|
|
|
|
|
| |
Like on other targets, we need to zero_extend/truncate i1 args before copying
them to GPRs.
llvm-svn: 203045
|
| |
|
|
|
|
|
|
| |
pointed to by the attribute, rather than the form as a first
step to determining how to hash the values. No functional change
intended.
llvm-svn: 203044
|
| |
|
|
|
|
|
|
| |
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).
llvm-svn: 203041
|
| |
|
|
|
|
| |
already lives.
llvm-svn: 203038
|
| |
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 203037
|
| |
|
|
|
|
|
|
| |
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.
llvm-svn: 203033
|
| |
|
|
| |
llvm-svn: 203032
|
| |
|
|
|
|
| |
for verbose asm.
llvm-svn: 203031
|
| |
|
|
| |
llvm-svn: 203023
|
| |
|
|
| |
llvm-svn: 203020
|
| |
|
|
|
|
| |
Thanks to Patrik Hägglund H for noticing it!
llvm-svn: 203019
|
| |
|
|
|
|
|
|
| |
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.
llvm-svn: 203018
|
| |
|
|
|
|
|
|
|
| |
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).
llvm-svn: 203015
|