| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In https://llvm.org/svn/llvm-project/polly/trunk@251870 code was committed to
avoid a failure in the presence of infinite loops, but the test case committed
along with this change passes without the actual change. I looked back into the
code and also checked with the original committer (Johannes), but could not find
the reason why the code is needed. The introduction of LoopStacks for
buildSchedule in one of the next commits will make it even more clear that this
code is not needed, but I remove this ahead of time to facilitate bisecting in
case I missed something.
llvm-svn: 259347
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D16755
llvm-svn: 259346
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Avoids unexpected overflows while performing pointer arithmetics in 64-bit code.
Moreover, neither PointerDiffType nor 'int' can be used as a common array index
type because arrays may have size (and indexes) more than PTRDIFF_MAX but less
than SIZE_MAX.
Patch by Aleksei Sidorin!
Differential Revision: http://reviews.llvm.org/D16063
llvm-svn: 259345
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- The patch solves Bug 23478 and Bug 19311. Resolving
Bug 23478 also resolves Bug 23039.
Correct ThreadStopInfo is set for Linux and FreeBSD
platforms.
- Summary:
When a trace event is reported, we need to check
whether the trace event lands at a breakpoint site.
If it lands at a breakpoint site then set the thread's
StopInfo with the reason 'breakpoint'. Else, set the reason
to be 'Trace'.
Change-Id: I0af9765e782fd74bc0cead41548486009f8abb87
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: jingham, emaste, lldb-commits, clayborg, ovyalov
Subscribers: emaste
Differential Revision: http://reviews.llvm.org/D16720
llvm-svn: 259344
|
| |
|
|
|
|
|
|
| |
Minor patch to trace back through target shuffles to the source of the inserted element in a (V)INSERTPS shuffle.
Differential Revision: http://reviews.llvm.org/D16652
llvm-svn: 259343
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D16752
llvm-svn: 259342
|
| |
|
|
|
|
|
|
|
| |
Noticed while working on scattered relocations.
I do not think these relocs can actually happen in the debug_info section,
but if they happen the code would mishandle them. Explicitely skip them
and warn if we encounter one.
llvm-svn: 259341
|
| |
|
|
|
|
|
|
| |
Remove unnecessary includes and class state.
No functional change intended.
llvm-svn: 259340
|
| |
|
|
|
|
|
|
|
|
| |
Although it seems like clang will never emit scattered relocations in
the debug information (at least I couldn't find a way), we have too
support them for the benefit of other compilers.
As clang doesn't generate them, the included testcase was produced
from hacked up assembly.
llvm-svn: 259339
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Those commits created an artificial edge from a cleanup to a synthesized
catchswitch in order to get the MSVC personality routine to execute
cleanups which don't cleanupret and are not wrapped by a catchswitch.
This worked well enough but is not a complete solution in situations
where there the cleanup infinite loops.
However, the real deal breaker behind this approach comes about from a
degenerate case where the cleanup is post-dominated by unreachable *and*
throws an exception. This ends poorly because the catchswitch will
inadvertently catch the exception.
Because of this we should go back to our previous behavior of not
executing certain cleanups (identical behavior with the Itanium ABI
implementation in clang, GCC and ICC).
N.B. I think this could be salvaged by making the catchpad rethrow the
exception and properly transforming throwing calls in the cleanup into
invokes.
llvm-svn: 259338
|
| |
|
|
| |
llvm-svn: 259337
|
| |
|
|
|
|
| |
of accidentally copying to a vector.
llvm-svn: 259336
|
| |
|
|
|
|
|
| |
We implemented this DR back in r258768 but forgot to mark it as
implemented.
llvm-svn: 259335
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With poorly chosen custom parameters, the line table encoding logic would
sometimes end up generating a special opcode bigger than 255, which is wrong.
The set of default parameters that LLVM uses isn't subject to this bug.
When carefully chosing the line table parameters, it's impossible to fall into the
corner case that this patch fixes. The standard however doesn't require that these
parameters be carefully chosen. And even if it did, we shouldn't generate broken
encoding.
Add a unittest for this specific encoding bug, and while at it, create some unit
tests for the encoding logic using different sets of parameters.
llvm-svn: 259334
|
| |
|
|
| |
llvm-svn: 259333
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
darwin requires the additional linkages of...
LLVMBitReader
LLVMMCParser
LLVMObject
LLVMProfileData
LLVMTarget
LLVMVectorize
as the darwin requires all of the weak undefined symbols in a library to be
resolved when linking it against an executable (unless
-Wl,-undefined,dynamic_lookup is used to override the default behavior of
-Wl,-undefined,error).
Contributed-by: Jack Howarth
llvm-svn: 259332
|
| |
|
|
| |
llvm-svn: 259331
|
| |
|
|
|
|
| |
efficient, its unclear the few places that were using the _32 version were doing so for efficiency.
llvm-svn: 259330
|
| |
|
|
|
|
| |
to use the std::string constructor that takes a start and end pointer. This saves a call to strlen. NFC
llvm-svn: 259329
|
| |
|
|
| |
llvm-svn: 259326
|
| |
|
|
| |
llvm-svn: 259325
|
| |
|
|
| |
llvm-svn: 259324
|
| |
|
|
| |
llvm-svn: 259323
|
| |
|
|
|
|
| |
function names, comments, formatting, typos
llvm-svn: 259322
|
| |
|
|
| |
llvm-svn: 259321
|
| |
|
|
|
|
| |
r259305 fixed a few assertions around FrameIndex, and I forgot to update these failures despite having run the torture tests.
llvm-svn: 259320
|
| |
|
|
|
|
| |
Damn case-insensitive filesystem...
llvm-svn: 259319
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
llvm-dsymutil was misinterpreting the value of common symbols as their
address when it actually contains their size. This didn't impact
llvm-dsymutil's ability to link the debug information for common symbols
because these are always found by name and not by address. Things could
however go wrong when the size of a common object matched the object
file address of another symbol. Depending on the link order of the symbols
the common object might incorrectly evict this other object from the
address to symbol mapping, and then link the evicted symbol with a wrong
binary address.
Use the new ability to have symbols without an object file address to fix
this.
llvm-svn: 259318
|
| |
|
|
|
|
|
|
|
|
|
| |
This change just changes the data structure that ties symbol names,
object file address and linked binary addresses to accept mappings
with no object file address. Such symbol mappings are not fed into
the debug map yet, so this patch is NFC.
A subsequent patch will make use of this functionality for common
symbols.
llvm-svn: 259317
|
| |
|
|
|
|
| |
efficient, its unclear that the one place using the _32 version was doing so for efficiency.
llvm-svn: 259316
|
| |
|
|
| |
llvm-svn: 259315
|
| |
|
|
| |
llvm-svn: 259314
|
| |
|
|
|
|
| |
intead of 20 as that's the largest string a 64-bit hex value can be.
llvm-svn: 259313
|
| |
|
|
| |
llvm-svn: 259312
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider the following ObjC++ snippet:
--
@protocol PA;
@protocol PB;
@class NSArray<ObjectType>;
typedef int some_t;
id<PA> FA(NSArray<id<PB>> *h, some_t group);
--
This would hit an assertion in the parser after generating an annotation token
while trying to update the token cache:
Assertion failed: (CachedTokens[CachedLexPos-1].getLastLoc() == Tok.getAnnotationEndLoc() && "The annotation should be until the most recent cached token")
...
7 clang::Preprocessor::AnnotatePreviousCachedTokens(clang::Token const&) + 494
8 clang::Parser::TryAnnotateTypeOrScopeTokenAfterScopeSpec(bool, bool, clang::CXXScopeSpec&, bool) + 1163
9 clang::Parser::TryAnnotateTypeOrScopeToken(bool, bool) + 361
10 clang::Parser::isCXXDeclarationSpecifier(clang::Parser::TPResult, bool*) + 598
...
The cached preprocessor token in this case is:
greatergreater '>>' Loc=<testcase.mm:7:24>
while the annotation ("NSArray<id<PB>>") ends at "testcase.mm:7:25", hence the
assertion.
Properly update the CachedTokens during template parsing to contain
two greater tokens instead of a greatergreater.
Differential Revision: http://reviews.llvm.org/D15173
rdar://problem/23494277
llvm-svn: 259311
|
| |
|
|
| |
llvm-svn: 259310
|
| |
|
|
|
|
| |
building a Twine. NFC
llvm-svn: 259309
|
| |
|
|
|
|
| |
added to a Twine. NFC
llvm-svn: 259308
|
| |
|
|
|
|
|
|
| |
1. Mentioned that CUDA support works best with trunk.
2. Simplified the example by removing its dependency on the CUDA samples.
3. Explain the --cuda-gpu-arch flag.
llvm-svn: 259307
|
| |
|
|
|
|
|
|
| |
Previously the code assumed all uses of FI on loads and stores were as
addresses. This checks whether the use is the address or a value and
handles the latter case as it does for non-memory instructions.
llvm-svn: 259306
|
| |
|
|
|
|
|
|
| |
The previous code was incorrect (can't getReg a frameindex). We could instead optimize it to reduce tree height, but I'm not sure that's worthwhile yet because we then try to eliminate the frameindex.
This patch also fixes frame index elimination for operations which may load or store: it used to assume the base was operand 2 and immediate offset operand 1. That's not true for stores, where they're 4 and 3.
llvm-svn: 259305
|
| |
|
|
| |
llvm-svn: 259304
|
| |
|
|
|
|
| |
WebAssemblyFrameLowering.cpp:158:44: warning: enumeral and non-enumeral type in conditional expression [enabled by default]
llvm-svn: 259303
|
| |
|
|
| |
llvm-svn: 259302
|
| |
|
|
| |
llvm-svn: 259301
|
| |
|
|
| |
llvm-svn: 259300
|
| |
|
|
| |
llvm-svn: 259299
|
| |
|
|
| |
llvm-svn: 259298
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The AMDGPUPromoteAlloca pass was emitting the read.local.size
calls, which with HSA was incorrectly selected to reading from
the offset mesa uses off of the kernarg pointer.
Error on intrinsics which aren't supported by HSA, and start
emitting the correct IR to read the workgroup size
out of the dispatch pointer.
Also initialize the pass so it can be tested with opt, and
start moving towards not depending on the subtarget as an
argument.
Start emitting errors for the intrinsics not handled with HSA.
llvm-svn: 259297
|
| |
|
|
|
|
|
|
| |
Only the dispatch.ptr intrinsic is supposed to be used now to get
the workgroup size, and the read.local.size intrinsics do not
work correctly.
llvm-svn: 259296
|