| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 232429
|
| |
|
|
| |
llvm-svn: 232428
|
| |
|
|
|
|
| |
bitcode
llvm-svn: 232427
|
| |
|
|
|
|
| |
from bitcode
llvm-svn: 232424
|
| |
|
|
|
|
|
| |
Instead, have the targets register a TargetStreamer to be use with the
asm streamer (if any).
llvm-svn: 232423
|
| |
|
|
|
|
|
|
| |
This makes the reader check the endianness of the object file its
given and behave appropriately. For the test I dug up a really old
linker and created a ppc-apple-darwin file for llvm-cov to read.
llvm-svn: 232422
|
| |
|
|
|
|
|
|
| |
(turns out I had regressed this when sinking handling of this type down
into GetElementPtrInst::Create - since that asserted before the error
handling was performed)
llvm-svn: 232420
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If `Verifier` has already found a failure, don't call
`DebugInfoVerifier`. The latter sometimes crashes in `DebugInfoFinder`
when the former would give a nice message. The only two cases I found
it crashing are explicit verifier tests I've added:
- test/Verifier/llvm.dbg.declare-expression.ll
- test/Verifier/llvm.dbg.value-expression.ll
However, I assume frontends with bugs will create invalid IR as well.
IMO, the `DebugInfoVerifier` should never crash (instead, it should fail
to verify), but subtleties like that will be easier to work out once
it's enabled again.
This is part of PR22777.
llvm-svn: 232418
|
| |
|
|
|
|
|
| |
Print out temporary `MDNode`s so we don't crash in the verifier (or
during `dump()` output).
llvm-svn: 232417
|
| |
|
|
|
|
| |
No need for local variables here.
llvm-svn: 232413
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we check `MDExpression` during `-verify` (r232299), make
the `DIExpression` wrapper more strict:
- remove redundant checks in `DebugInfoVerifier`,
- overload `get()` to `cast_or_null<MDExpression>` (superseding
`getRaw()`),
- stop checking for null in any accessor, and
- remove `DIExpression::Verify()` entirely in favour of
`MDExpression::isValid()`.
There is still some logic in this class, mostly to do with high-level
iterators; I'll defer cleaning up those until the rest of the wrappers
are similarly strict.
llvm-svn: 232412
|
| |
|
|
|
|
|
|
|
|
| |
Clarify the logic in `DIType::Verify()` by checking `isBasicType()`
earlier, by skipping `else` after `return`s, and by documenting an
otherwise opaque check.
No functionality change.
llvm-svn: 232410
|
| |
|
|
|
|
|
|
|
|
|
| |
Turns out `visitIntrinsicFunctionCall()` descends into all operands
already, so explicitly descending in `visitDbgIntrinsic()` (part of
r232296) isn't useful.
Updating a testcase that doesn't really need `-verify-debug-info` (since
r231082) as confirmation.
llvm-svn: 232408
|
| |
|
|
|
|
|
|
|
| |
r230877 optimized which fields are written out for `CHECK`-ability, but
apparently missed changing some of them to optional in `LLParser`.
Fixes PR22921.
llvm-svn: 232400
|
| |
|
|
|
|
|
|
|
| |
uppercase letter
This covers essentially all of llvm's headers and libs. One or two weird
cases I wasn't sure were worth/appropriate to fix.
llvm-svn: 232394
|
| |
|
|
|
|
|
|
|
|
| |
are not at the file level.
Previously, the default subtarget created from the target triple was used to
emit inline asm instructions. Compilation would fail in cases where the feature
bits necessary to assemble an inline asm instruction in a function weren't set.
llvm-svn: 232392
|
| |
|
|
| |
llvm-svn: 232388
|
| |
|
|
|
|
|
|
|
|
| |
There are no opcodes for this. This also adds a test case.
v2: make test more robust
Patch by: Grigori Goronzy
llvm-svn: 232386
|
| |
|
|
| |
llvm-svn: 232385
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix justify error for small structures bigger than 32 bits in fixed
arguments for MIPS64 big endian. There was a problem when small structures
are passed as fixed arguments. The structures that are bigger than 32 bits
but smaller than 64 bits were not left justified properly on MIPS64 big
endian. This is fixed by shifting the value to make it left justified when
appropriate.
Patch by Aleksandar Beserminji.
Differential Revision: http://reviews.llvm.org/D8174
llvm-svn: 232382
|
| |
|
|
| |
llvm-svn: 232378
|
| |
|
|
|
|
|
|
| |
memory constraints.
2007-12-17-InvokeAsm.ll fails on the buildbot but not on my own system. Will investigate.
llvm-svn: 232376
|
| |
|
|
| |
llvm-svn: 232375
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
But still handle them the same way since I don't know how they differ on
this target.
No functional change intended.
Reviewers: kparzysz, adasgupt
Reviewed By: kparzysz, adasgupt
Subscribers: colinl, llvm-commits
Differential Revision: http://reviews.llvm.org/D8204
llvm-svn: 232374
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
InlineAsm::Constraint_m. NFC.
Summary:
This is instead of doing this in target independent code and is the last
non-functional change before targets begin to distinguish between
different memory constraints when selecting code for the ISD::INLINEASM
node.
Next, each target will individually move away from the idea that all
memory constraints behave like 'm'.
Subscribers: jholewinski, llvm-commits
Differential Revision: http://reviews.llvm.org/D8173
llvm-svn: 232373
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Make the code more readable by outlining NOP creation.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8320
llvm-svn: 232371
|
| |
|
|
| |
llvm-svn: 232368
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch consists of the suggestions of clang-tidy/misc-static-assert check.
Reviewers: alexfh
Reviewed By: alexfh
Subscribers: xazax.hun, llvm-commits
Differential Revision: http://reviews.llvm.org/D8343
llvm-svn: 232366
|
| |
|
|
|
|
|
|
|
| |
As pointed out in http://reviews.llvm.org/D7583
The current checks can cause overflows when object size/access offset cross Quintillion bytes.
http://reviews.llvm.org/D8193
llvm-svn: 232358
|
| |
|
|
| |
llvm-svn: 232357
|
| |
|
|
| |
llvm-svn: 232356
|
| |
|
|
| |
llvm-svn: 232355
|
| |
|
|
| |
llvm-svn: 232352
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
non-safe in both direction, but mitigate the problem by noting that we just care if there was a further use.
The problem here is the infamous one direction known safe. I was
hesitant to turn it off before b/c of the potential for regressions
without an actual bug from users hitting the problem. This is that bug ;
).
The main performance impact of having known safe in both directions is
that often times it is very difficult to find two releases without a use
in-between them since we are so conservative with determining potential
uses. The one direction known safe gets around that problem by taking
advantage of many situations where we have two retains in a row,
allowing us to avoid that problem. That being said, the one direction
known safe is unsafe. Consider the following situation:
retain(x)
retain(x)
call(x)
call(x)
release(x)
Then we know the following about the reference count of x:
// rc(x) == N (for some N).
retain(x)
// rc(x) == N+1
retain(x)
// rc(x) == N+2
call A(x)
call B(x)
// rc(x) >= 1 (since we can not release a deallocated pointer).
release(x)
// rc(x) >= 0
That is all the information that we can know statically. That means that
we know that A(x), B(x) together can release (x) at most N+1 times. Lets
say that we remove the inner retain, release pair.
// rc(x) == N (for some N).
retain(x)
// rc(x) == N+1
call A(x)
call B(x)
// rc(x) >= 1
release(x)
// rc(x) >= 0
We knew before that A(x), B(x) could release x up to N+1 times meaning
that rc(x) may be zero at the release(x). That is not safe. On the other
hand, consider the following situation where we have a must use of
release(x) that x must be kept alive for after the release(x)**. Then we
know that:
// rc(x) == N (for some N).
retain(x)
// rc(x) == N+1
retain(x)
// rc(x) == N+2
call A(x)
call B(x)
// rc(x) >= 2 (since we know that we are going to release x and that that release can not be the last use of x).
release(x)
// rc(x) >= 1 (since we can not deallocate the pointer since we have a must use after x).
…
// rc(x) >= 1
use(x)
Thus we know that statically the calls to A(x), B(x) can together only
release rc(x) N times. Thus if we remove the inner retain, release pair:
// rc(x) == N (for some N).
retain(x)
// rc(x) == N+1
call A(x)
call B(x)
// rc(x) >= 1
…
// rc(x) >= 1
use(x)
We are still safe unless in the final … there are unbalanced retains,
releases which would have caused the program to blow up anyways even
before optimization occurred. The simplest form of must use is an
additional release that has not been paired up with any retain (if we
had paired the release with a retain and removed it we would not have
the additional use). This fits nicely into the ARC framework since
basically what you do is say that given any nested releases regardless
of what is in between, the inner release is known safe. This enables us to get
back the lost performance.
<rdar://problem/19023795>
llvm-svn: 232351
|
| |
|
|
|
|
|
|
|
| |
decrementing them.
This will be tested in the next commit (which required it). The commit
is going to update a bunch of tests at the same time.
llvm-svn: 232350
|
| |
|
|
|
|
| |
This is a name that is more descriptive of what the method really does. NFC.
llvm-svn: 232349
|
| |
|
|
|
|
| |
also made it lazy.
llvm-svn: 232348
|
| |
|
|
|
|
| |
ARCRuntimeEntryPoints called ARCRuntimeEntryPointKind.
llvm-svn: 232347
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This code was casting regions of a memory buffer to a couple of
different structs. This is wrong in a few ways:
1. It breaks aliasing rules.
2. If the buffer isn't aligned, it hits undefined behaviour.
3. It completely ignores endianness differences.
4. The structs being defined for this aren't specifying their padding
properly, so this doesn't even represent the data properly on some
platforms.
This commit is mostly NFC, except that it fixes reading coverage for
32 bit binaries as a side effect of getting rid of the mispadded
structs. I've included a test for that.
I've also baked in that we only handle little endian more explicitly,
since that was true in practice already. I'll fix this to handle
endianness properly in a followup commit.
llvm-svn: 232346
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
No need to emit a DW_LNS_advance_pc with a 0 increment. Found out while
comparing dsymutil's and LLVM's line table encoding. Not a correctenss
fix, just a small encoding size optimization.
I'm not sure how to generate a sequence that triggers this, and moreover
llvm-dwardump doesn't dump the line table program, thus the effort
involved in creating a testcase for this trivial patch seemed out of
proportion.
llvm-svn: 232332
|
| |
|
|
| |
llvm-svn: 232331
|
| |
|
|
| |
llvm-svn: 232328
|
| |
|
|
| |
llvm-svn: 232327
|
| |
|
|
| |
llvm-svn: 232325
|
| |
|
|
|
|
|
|
|
|
| |
Use an overload instead of a default argument for `Metadata::dump()`.
The latter seems to require calling `dump(nullptr)` explicitly when
using a debugger, where as the former doesn't.
Other than utility for debugging, there's NFC here.
llvm-svn: 232315
|
| |
|
|
|
|
|
| |
Change accessors to downcast to `MDLocalVariable` and `MDExpression`,
now that we have -verify checks in place to confirm that it's safe.
llvm-svn: 232299
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Verify that debug info intrinsic arguments are valid. (These checks
will not recurse through the full debug info graph, so they don't need
to be cordoned of in `DebugInfoVerifier`.)
With those checks in place, changing the `DbgIntrinsicInst` accessors to
downcast to `MDLocalVariable` and `MDExpression` is natural (added isa
specializations in `Metadata.h` to support this).
Added tests to `test/Verifier` for the new -verify checks, and fixed the
debug info in all the in-tree tests.
If you have out-of-tree testcases that have started to fail to -verify,
hopefully the verify checks are helpful. The most likely problem is
that the expression argument is `!{}` (instead of `!MDExpression()`).
llvm-svn: 232296
|
| |
|
|
| |
llvm-svn: 232294
|
| |
|
|
|
|
| |
So everyone's lives are easier in the future
llvm-svn: 232293
|
| |
|
|
|
|
|
| |
This is already assumed to be non-null above due to a dyn_cast<>. Also
remove extraneous braces around statement.
llvm-svn: 232292
|