| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 153165
|
| |
|
|
|
|
|
|
|
| |
the migration to ModuleSpec objects this broke and is now fixed.
Also fixed a case in the darwin kernel dynamic loader where we just need to
trust the load address of the kernel if we can't read it from memory.
llvm-svn: 153164
|
| |
|
|
| |
llvm-svn: 153163
|
| |
|
|
| |
llvm-svn: 153162
|
| |
|
|
| |
llvm-svn: 153161
|
| |
|
|
| |
llvm-svn: 153160
|
| |
|
|
| |
llvm-svn: 153159
|
| |
|
|
| |
llvm-svn: 153158
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This gives a lot of love to the docs for the C API. Like Clang's
documentation, the C API is now organized into a Doxygen "module"
(LLVMC). Each C header file is a child of the main module. Some modules
(like Core) have a hierarchy of there own. The produced documentation is
thus better organized (before everything was in one monolithic list).
This patch also includes a lot of new documentation for APIs in Core.h.
It doesn't document them all, but is better than none. Function docs are
missing @param and @return annotation, but the documentation body now
commonly provides help details (like the expected llvm::Value sub-type
to expect).
llvm-svn: 153157
|
| |
|
|
|
|
| |
(StringRef)getName() can be used here.
llvm-svn: 153156
|
| |
|
|
| |
llvm-svn: 153155
|
| |
|
|
|
|
| |
shuffle elements for consistency with other shuffle code in X86 backend.
llvm-svn: 153154
|
| |
|
|
|
|
|
|
| |
These changes allow us to compile big endian from the command line for 32 bit
Mips targets. This patch will result in code and data actually being produced
in the correct endianess.
llvm-svn: 153153
|
| |
|
|
|
|
|
|
| |
of references to function template parameters in noexcept clauses when
the instantiation is forced from a point during parsing when a block
is in scope.
llvm-svn: 153152
|
| |
|
|
|
|
| |
// rdar://11076938
llvm-svn: 153151
|
| |
|
|
| |
llvm-svn: 153150
|
| |
|
|
| |
llvm-svn: 153149
|
| |
|
|
|
|
|
|
|
|
|
|
| |
ImmutAVLTree uses random unsigned values as keys into a DenseMap,
which could possibly happen to be the same value as the Tombstone or
Entry keys in the DenseMap.
Test case is hard to come up with. We randomly get failures on the
internal static analyzer bot, which most likely hits this issue
(hard to be 100% sure without the full stack).
llvm-svn: 153148
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
relocations (i.e., pieces of data whose addresses
are referred to elsewhere in the binary image) and
update the references when the section containing
the relocations moves. The way this works is that
there is a map from section IDs to lists of
relocations.
Because the relocations are associated with the
section containing the data being referred to, they
are updated only when the target moves. However,
many data references are relative and also depend
on the location of the referrer.
To solve this problem, I introduced a new data
structure, Referrer, which simply contains the
section being referred to and the index of the
relocation in that section. These referrers are
associated with the source containing the
reference that needs to be updated, so now
regardless of which end of the relocation moves,
the relocation will now be updated correctly.
llvm-svn: 153147
|
| |
|
|
| |
llvm-svn: 153146
|
| |
|
|
|
|
| |
// rdar://11079898
llvm-svn: 153145
|
| |
|
|
| |
llvm-svn: 153142
|
| |
|
|
|
|
| |
the external link.
llvm-svn: 153141
|
| |
|
|
| |
llvm-svn: 153140
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vextractf128 with 128-bit mem dest.
Combines
vextractf128 $0, %ymm0, %xmm0
vmovaps %xmm0, (%rdi)
to
vextractf128 $0, %ymm0, (%rdi)
rdar://11082570
llvm-svn: 153139
|
| |
|
|
|
|
|
| |
the class pointer in the category structure.
// rdar://11076938
llvm-svn: 153138
|
| |
|
|
|
|
| |
rdar://11027851
llvm-svn: 153137
|
| |
|
|
| |
llvm-svn: 153136
|
| |
|
|
|
|
| |
t2PseudoExpand.
llvm-svn: 153135
|
| |
|
|
|
|
|
|
| |
Do not call SplitBlockPredecessors on a loop preheader when one of the
predecessors is an indirectbr. Otherwise, you will hit this assert:
!isa<IndirectBrInst>(Preds[i]->getTerminator()) && "Cannot split an edge from an IndirectBrInst"
llvm-svn: 153134
|
| |
|
|
| |
llvm-svn: 153133
|
| |
|
|
| |
llvm-svn: 153132
|
| |
|
|
|
|
|
|
|
| |
instead of skipping the current loop.
My prior fix was incomplete because of an overzealous compile-time optimization:
Better fix for: <rdar://problem/11049788> Segmentation fault: 11 in LoopStrengthReduce
llvm-svn: 153131
|
| |
|
|
| |
llvm-svn: 153130
|
| |
|
|
| |
llvm-svn: 153129
|
| |
|
|
|
|
| |
expression parser code.
llvm-svn: 153128
|
| |
|
|
| |
llvm-svn: 153127
|
| |
|
|
| |
llvm-svn: 153126
|
| |
|
|
| |
llvm-svn: 153125
|
| |
|
|
| |
llvm-svn: 153124
|
| |
|
|
| |
llvm-svn: 153123
|
| |
|
|
|
|
| |
<rdar://problem/11040133>.
llvm-svn: 153122
|
| |
|
|
|
|
|
|
| |
invalidating the pointer.
Fixes PR12284. The test case only triggered under asan/valgrind, but it's better than nothing.
llvm-svn: 153120
|
| |
|
|
|
|
|
| |
via functions for certain pointer initialization
fields. // rdar://11076938
llvm-svn: 153117
|
| |
|
|
| |
llvm-svn: 153116
|
| |
|
|
|
|
|
|
| |
replaceOperandWith.
TrackingVH notices when it gets RAUW'd. Fixes PR12305 and PR12315.
llvm-svn: 153115
|
| |
|
|
|
|
| |
precedence over the VINSERTF128 avx1 patterns.
llvm-svn: 153114
|
| |
|
|
| |
llvm-svn: 153113
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ARMBaseRegisterInfo::canRealignStack was checking for variable-sized objects
but not for stack adjustments around calls. Use hasReservedCallFrame() to
check for both. The hasBasePointer function was already correctly checking
both conditions, so the effect of this was that a base pointer would be used
without checking whether the base pointer register could be reserved. I don't
have a small testcase for this.
<rdar://problem/11075906>
llvm-svn: 153110
|
| |
|
|
|
|
|
| |
ARMFrameLowering::hasReservedCallFrame is already checking for variable
sized objects, so there's no point in checking it twice.
llvm-svn: 153109
|