Age | Commit message (Collapse) | Author | Files | Lines |
|
The bitset metadata currently used in LLVM has a few problems:
1. It has the wrong name. The name "bitset" refers to an implementation
detail of one use of the metadata (i.e. its original use case, CFI).
This makes it harder to understand, as the name makes no sense in the
context of virtual call optimization.
2. It is represented using a global named metadata node, rather than
being directly associated with a global. This makes it harder to
manipulate the metadata when rebuilding global variables, summarise it
as part of ThinLTO and drop unused metadata when associated globals are
dropped. For this reason, CFI does not currently work correctly when
both CFI and vcall opt are enabled, as vcall opt needs to rebuild vtable
globals, and fails to associate metadata with the rebuilt globals. As I
understand it, the same problem could also affect ASan, which rebuilds
globals with a red zone.
This patch solves both of those problems in the following way:
1. Rename the metadata to "type metadata". This new name reflects how
the metadata is currently being used (i.e. to represent type information
for CFI and vtable opt). The new name is reflected in the name for the
associated intrinsic (llvm.type.test) and pass (LowerTypeTests).
2. Attach metadata directly to the globals that it pertains to, rather
than using the "llvm.bitsets" global metadata node as we are doing now.
This is done using the newly introduced capability to attach
metadata to global variables (r271348 and r271358).
See also: http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html
Differential Revision: http://reviews.llvm.org/D21053
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273729 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Lei Zhang!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273726 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a resubmittion of previously reverted rL273568.
This is a fix for the problem mentioned in "LTO and intrinsics mangling" llvm-dev mail thread:
http://lists.llvm.org/pipermail/llvm-dev/2016-April/098387.html
Reviewers: mehdi_amini, reames
Differential Revision: http://reviews.llvm.org/D19373
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273686 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It broke 2008-07-15-Bswap.ll and 2009-09-01-PostRAProlog.ll
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273574 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a fix for the problem mentioned in "LTO and intrinsics mangling" llvm-dev mail thread:
http://lists.llvm.org/pipermail/llvm-dev/2016-April/098387.html
Reviewers: mehdi_amini, reames
Differential Revision: http://reviews.llvm.org/D19373
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273568 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
issue with globals.
This change is motivated by an upcoming change to the metadata representation
used for CFI. The indirect function call checker needs type information for
external function declarations in order to correctly generate jump table
entries for such declarations. We currently associate such type information
with declarations using a global metadata node, but I plan [1] to move all
such metadata to global object attachments.
In bitcode, metadata attachments for function declarations appear in the
global metadata block. This seems reasonable to me because I expect metadata
attachments on declarations to be uncommon. In the long term I'd also expect
this to be the case for CFI, because we'd want to use some specialized bitcode
format for this metadata that could be read as part of the ThinLTO thin-link
phase, which would mean that it would not appear in the global metadata block.
To solve the lazy loaded metadata issue I was seeing with D20147, I use the
same bitcode representation for metadata attachments for global variables as I
do for function declarations. Since there's a use case for metadata attachments
in the global metadata block, we might as well use that representation for
global variables as well, at least until we have a mechanism for lazy loading
global variables.
In the assembly format, the metadata attachments appear after the "declare"
keyword in order to avoid a parsing ambiguity.
[1] http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html
Differential Revision: http://reviews.llvm.org/D21052
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273336 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Reviewers: george.burgess.iv, gberry, hfinkel
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D21463
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273295 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273262 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
GetFinalPathNameByHandle API does not behave as documented; if given a buffer that has enough space for the path but not the null terminator, the call will return the number of characters required *without* the null terminator (despite being documented otherwise) and it will not set GetLastError(). The result was that this function would return a bogus path and no error. Instead, ensure there is sufficient space for a null terminator (we already strip it off manually for compatibility with older versions of Windows).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273195 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We recently made MemorySSA own the walker it creates. As a part of this,
the MSSA test fixture was changed to have a `Walker*` instead of a
`unique_ptr<Walker>`. So, we no longer need to do `&*Walker` in order to
get a `Walker*`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273189 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
prior to some very substantial patches to isolate any formatting-only
changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272991 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
pass manager passes' `run` methods.
This removes a bunch of SFINAE goop from the pass manager and just
requires pass authors to accept `AnalysisManager<IRUnitT> &` as a dead
argument. This is a small price to pay for the simplicity of the system
as a whole, despite the noise that changing it causes at this stage.
This will also helpfull allow us to make the signature of the run
methods much more flexible for different kinds af passes to support
things like intelligently updating the pass's progression over IR units.
While this touches many, many, files, the changes are really boring.
Mostly made with the help of my trusty perl one liners.
Thanks to Sean and Hal for bouncing ideas for this with me in IRC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272978 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Current implementation leaves the object in an invalid state.
This reverts commit bf0c389ac683cd6c0e5959b16537e59e5f4589e3.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272965 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
BranchProbabilityInfo"
It was causing failures in Profile-i386 and Profile-x86_64 tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272912 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We should update results of the BranchProbabilityInfo after removing block in JumpThreading. Otherwise
we will get dangling pointer inside BranchProbabilityInfo cache.
Differential Revision: http://reviews.llvm.org/D20957
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272891 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It will be used in clang.
Patch by Lei Zhang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272660 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
including case -- so that clang can later warn about non-portable #include and #import directives.
Differential Revision: http://reviews.llvm.org/D19842
Corresponding clang patch: http://reviews.llvm.org/D19843
Re-commit after addressing issues with of generating too many warnings for Windows and asan test failures
Patch by Eric Niebler
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272555 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
temporary object to ArrayRef.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272457 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
undef uses are no real uses of a register and must be ignored by
findLastUseBefore() so that handleMove() does not produce invalid live
intervals in some cases.
This fixed http://llvm.org/PR28083
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272446 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272440 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This fixes an alignment issue by forcing all cached allocations
to be 8 byte aligned, and also fixes an issue arising on big
endian systems by writing ulittle32_t's instead of uint32_t's
in the test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272437 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This adds method and tests for writing to a PDB stream. With
this, even a PDB stream which is discontiguous can be treated
as a sequential stream of bytes for the purposes of writing.
Reviewed By: ruiu
Differential Revision: http://reviews.llvm.org/D21157
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272369 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Now DISubroutineType has a 'cc' field which should be a DW_CC_ enum. If
it is present and non-zero, the backend will emit it as a
DW_AT_calling_convention attribute. On the CodeView side, we translate
it to the appropriate enum for the LF_PROCEDURE record.
I added a new LLVM vendor specific enum to the list of DWARF calling
conventions. DWARF does not appear to attempt to standardize these, so I
assume it's OK to do this until we coordinate with GCC on how to emit
vectorcall convention functions.
Reviewers: dexonsmith, majnemer, aaboud, amccarth
Subscribers: mehdi_amini, llvm-commits
Differential Revision: http://reviews.llvm.org/D21114
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272197 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272174 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The architecture enumeration is shared across ARM and AArch64. However, the
data is not. The code incorrectly would index into the array using the
architecture index which was offset by the ARMv7 architecture enumeration. We
do not have a marker for indicating the architectural family to which the
enumeration belongs so we cannot be clever about offsetting the index (at least
it is not immediately apparent to me). Instead, fall back to the tried-and-true
method of slowly iterating the array (its not a large array, so the impact of
this is not too high).
Because of the incorrect indexing, if we were lucky, we would crash, but usually
we would return an invalid StringRef. We did not have any tests for the AArch64
target parser previously;. Extend the previous tests I had added for ARM to
cover AArch64 for ensuring that we return expected StringRefs.
Take the opportunity to change some iterator types to references.
This work is needed to support parsing `.arch name` directives in the AArch64
target asm parser.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272145 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272059 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This allows mapping of any endian-aware type whose underlying
type (e.g. uint32_t) provides a ScalarTraits specialization.
Reviewed by: majnemer
Differential Revision: http://reviews.llvm.org/D21057
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272049 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271983 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
functions.
Arrange to call verify(Function &) on each function, followed by
verify(Module &), whether the verifier is being used from the pass or
from verifyModule(). As a side effect, this fixes an issue that caused
us not to call verify(Function &) on unmaterialized functions from
verifyModule().
Differential Revision: http://reviews.llvm.org/D21042
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271956 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
(Yes, this only deadlocks on a computer with a single core; I'm using
a virtual machine.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271855 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
#include and #import paths (Corresponding clang patch has been reverted by r271761). Patches are reverted because they generate lots of unadressable warnings for windows and fail tests under ASAN.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271764 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
including case -- so that clang can later warn about non-portable #include and #import directives.
Differential Revision: http://reviews.llvm.org/D19842
Patch by Eric Niebler
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271704 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
http://reviews.llvm.org/D20930
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271669 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also fix slice wrappers drop_front and drop_back.
The unittests are pretty awkward, but do the job; alternatives
welcome!
..and yes, I do have ArrayRefs with more than 4 billion elements.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271546 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
In r271380, I added several functions to get the minimum/maximum values
of n-width integers.
This just adds tests for them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271505 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We only considered the length of the operation and the length of the
StreamRef without considered what it meant for the offset to be at a
non-zero position.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271496 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271441 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271439 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Add support for the new pass manager to MemorySSA pass.
Change MemorySSA to be computed eagerly upon construction.
Change MemorySSAWalker to be owned by the MemorySSA object that creates
it.
Reviewers: dberlin, george.burgess.iv
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D19664
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271432 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271420 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271418 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271416 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271397 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This will be necessary to allow the global merge pass to attach
multiple debug info metadata nodes to global variables once we reverse
the edge from DIGlobalVariable to GlobalVariable.
Differential Revision: http://reviews.llvm.org/D20414
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271358 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271355 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This tidies up some code that was manually constructing RuntimeDyld::SymbolInfo
instances from JITSymbols. It will save more mess in the future when
JITSymbol::getAddress is extended to return an Expected<TargetAddress> rather
than just a TargetAddress, since we'll be able to embed the error checking in
the conversion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271350 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential Revision: http://reviews.llvm.org/D20837
Reviewed By: ruiu
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271346 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Based on a totally scientific, 30 second google search "in-" appears to be the
preferred prefix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270950 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
StringError can be used to represent Errors that aren't recoverable based on
the error type, but that have a useful error message that can be reported to
the user or logged.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270948 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
APInt::slt was copying the LHS and RHS in to temporaries then making
them unsigned so that it could use an unsigned comparision. It did
this even on the paths which were trivial to give results for, such
as the sign bit of the LHS being set while RHS was not set.
This changes the logic to return out immediately in the trivial cases,
and use an unsigned comparison in the remaining cases. But this time,
just use the unsigned comparison directly without creating any temporaries.
This works because, for example:
true = (-2 slt -1) = (0xFE ult 0xFF)
Also added some tests explicitly for slt with APInt's larger than 64-bits
so that this new code is tested.
Using the memory for 'opt -O2 verify-uselistorder.lto.opt.bc -o opt.bc'
(see r236629 for details), this reduces the number of allocations from
26.8M to 23.9M.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270881 91177308-0d34-0410-b5e6-96231b3b80d8
|