| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
Currently in JumpThreading pass, the branch weight metadata is not updated after CFG modification. Consider the jump threading on PredBB, BB, and SuccBB. After jump threading, the weight on BB->SuccBB should be adjusted as some of it is contributed by the edge PredBB->BB, which doesn't exist anymore. This patch tries to update the edge weight in metadata on BB->SuccBB by scaling it by 1 - Freq(PredBB->BB) / Freq(BB->SuccBB).
This is the third attempt to submit this patch, while the first two led to failures in some FDO tests. After investigation, it is the edge weight normalization that caused those failures. In this patch the edge weight normalization is fixed so that there is no zero weight in the output and the sum of all weights can fit in 32-bit integer. Several unit tests are added.
Differential revision: http://reviews.llvm.org/D10979
llvm-svn: 250345
|
|
|
|
| |
llvm-svn: 250077
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows, fs::rename() could fail is another process was reading the
file at the same time using fs::openFileForRead(). In most cases the user
wouldn't notice as fs::rename() will continue to retry for 2000ms. Typically
this is enough for the read to complete and a retry to succeed, but if the
disk is being it too hard then the response time might be longer than the
retry time and the rename would fail with a permission error.
Add FILE_SHARE_DELETE to the sharing flags for CreateFileW() in
fs::openFileForRead() and try ReplaceFileW() prior to MoveFileExW()
in fs::rename().
Based on an initial patch by Edd Dawson!
Differential Revision: http://reviews.llvm.org/D13647
llvm-svn: 250046
|
|
|
|
|
|
|
| |
While here fix a few more issues with potential overflow and add
new tests for these cases. Ensured that test now passes with UBSan.
llvm-svn: 249745
|
|
|
|
| |
llvm-svn: 249320
|
|
|
|
|
|
| |
This will be used soon from clang.
llvm-svn: 249309
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As per Duncan's review for D12536, I extracted the sub-byte bit aligned
reading and writing code into lib/Support, and generalized it. Added calls from
BackpatchWord. Also added unittests.
Reviewers: dexonsmith
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13189
llvm-svn: 248897
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
HHVM calling convention, hhvmcc, is used by HHVM JIT for
functions in translated cache. We currently support LLVM back end to
generate code for X86-64 and may support other architectures in the
future.
In HHVM calling convention any GP register could be used to pass and
return values, with the exception of R12 which is reserved for
thread-local area and is callee-saved. Other than R12, we always
pass RBX and RBP as args, which are our virtual machine's stack pointer
and frame pointer respectively.
When we enter translation cache via hhvmcc function, we expect
the stack to be aligned at 16 bytes, i.e. skewed by 8 bytes as opposed
to standard ABI alignment. This affects stack object alignment and stack
adjustments for function calls.
One extra calling convention, hhvm_ccc, is used to call C++ helpers from
HHVM's translation cache. It is almost identical to standard C calling
convention with an exception of first argument which is passed in RBP
(before we use RDI, RSI, etc.)
Differential Revision: http://reviews.llvm.org/D12681
llvm-svn: 248832
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BranchProbability now is represented by its numerator and denominator in uint32_t type. This patch changes this representation into a fixed point that is represented by the numerator in uint32_t type and a constant denominator 1<<31. This is quite similar to the representation of BlockMass in BlockFrequencyInfoImpl.h. There are several pros and cons of this change:
Pros:
1. It uses only a half space of the current one.
2. Some operations are much faster like plus, subtraction, comparison, and scaling by an integer.
Cons:
1. Constructing a probability using arbitrary numerator and denominator needs additional calculations.
2. It is a little less precise than before as we use a fixed denominator. For example, 1 - 1/3 may not be exactly identical to 1 / 3 (this will lead to many BranchProbability unit test failures). This should not matter when we only use it for branch probability. If we use it like a rational value for some precise calculations we may need another construct like ValueRatio.
One important reason for this change is that we propose to store branch probabilities instead of edge weights in MachineBasicBlock. We also want clients to use probability instead of weight when adding successors to a MBB. The current BranchProbability has more space which may be a concern.
Differential revision: http://reviews.llvm.org/D12603
llvm-svn: 248633
|
|
|
|
|
|
| |
small. NFC.
llvm-svn: 247357
|
|
|
|
|
|
|
| |
splits to actually use the single character split routine which does
less work, and in a debug build is *substantially* faster.
llvm-svn: 247245
|
|
|
|
|
|
| |
And make it more robust in the edge case of exactly "./" as input.
llvm-svn: 246711
|
|
|
|
| |
llvm-svn: 244854
|
|
|
|
| |
llvm-svn: 244848
|
|
|
|
| |
llvm-svn: 244268
|
|
|
|
|
|
|
|
|
|
|
|
| |
'llvm::TrailingObjects<`anonymous-namespace'::Class1,short,llvm::NoTrailingTypeArg>::additionalSizeToAlloc' :
cannot access protected member declared in class
'llvm::TrailingObjects<`anonymous-namespace'::Class1,short,llvm::NoTrailingTypeArg>'
I'm not sure how this compiles with gcc.
Aren't protecteded members accessible only with protected or public inheritance?
llvm-svn: 244199
|
|
|
|
|
|
|
|
|
|
| |
This is intended to help support the idiom of a class that has some
other objects (or multiple arrays of different types of objects)
appended on the end, which is used quite heavily in clang.
Differential Revision: http://reviews.llvm.org/D11272
llvm-svn: 244164
|
|
|
|
| |
llvm-svn: 240112
|
|
|
|
|
|
|
|
| |
the value in an optional mapping).
This change breaks clang-format tests.
llvm-svn: 239976
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
optional mapping.
This commit ensures that a value that's passed into YAML's IO mapOptional method
is going to be assigned a value returned by the default constructor for that
value's type when the appropriate key is not present in the YAML mapping.
Reviewers: Duncan P. N. Exon Smith
Differential Revision: http://reviews.llvm.org/D10492
llvm-svn: 239972
|
|
|
|
|
|
| |
We were already deleting it, this just makes it explicit.
llvm-svn: 239867
|
|
|
|
| |
llvm-svn: 239804
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As noted on Errc.h:
// * std::errc is just marked with is_error_condition_enum. This means that
// common patters like AnErrorCode == errc::no_such_file_or_directory take
// 4 virtual calls instead of two comparisons.
And on some libstdc++ those virtual functions conclude that
------------------------
int main() {
std::error_code foo = std::make_error_code(std::errc::no_such_file_or_directory);
return foo == std::errc::no_such_file_or_directory;
}
-------------------------
should exit with 0.
llvm-svn: 239683
|
|
|
|
|
|
|
|
|
|
|
|
| |
StringSaver now always saves to a BumpPtrAllocator.
The only reason for having the virtual saveImpl is so lld can have a
thread safe version.
The reason for the distinct BumpPtrStringSaver class is to avoid the
virtual destructor.
llvm-svn: 239669
|
|
|
|
|
|
|
| |
Hope this fixes the bits, eg:
http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/27147
llvm-svn: 238586
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We would wrap flow mappings and sequences when they go over a hardcoded 70
characters limit. Make the wrapping column configurable (and default to 70
co the change should be NFC for current users). Passing 0 allows to completely
suppress the wrapping which makes it easier to handle in tools like FileCheck.
Reviewers: bogner
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10109
llvm-svn: 238584
|
|
|
|
| |
llvm-svn: 237970
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The commit null terminates the string value in the `yaml::BlockScalarNode`
class.
This change is motivated by the initial MIR serialization commit (r237708)
that I reverted in r237730 because the LLVM IR source from the block
scalar node wasn't terminated by a null character and thus the buildbots
failed on one testcase sometimes. This change enables me to recommit
the reverted commit.
llvm-svn: 237942
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The existing code for method StreamingMemoryObject.fetchToPos does not respect
the corresonding call to setKnownObjectSize(). As a result, it allows the
StreamingMemoryObject to read bytes past the object size.
This patch provides a test case, and code to fix the problem.
Patch by Karl Schimpf
Differential Revision: http://reviews.llvm.org/D8931
llvm-svn: 237939
|
|
|
|
| |
llvm-svn: 237795
|
|
|
|
|
|
|
|
| |
BumpPtrAllocator's Reset wouldn't clear CustomSizedSlabs if Slabs.size() == 0.
Patch by Kal <b17c0de@gmail.com>!
llvm-svn: 237588
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit gives the users of the YAML Traits I/O library
the ability to serialize scalars using the YAML literal block
scalar notation by allowing them to implement a specialization
of the `BlockScalarTraits` struct for their custom types.
Reviewers: Duncan P. N. Exon Smith
Differential Revision: http://reviews.llvm.org/D9613
llvm-svn: 237404
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit implements the parsing of YAML block scalars.
Some code existed for it before, but it couldn't parse block
scalars.
This commit adds a new yaml node type to represent the block
scalar values.
This commit also deletes the 'spec-09-27' and 'spec-09-28' tests
as they are identical to the test file 'spec-09-26'.
This commit introduces 3 new utility functions to the YAML scanner
class: `skip_s_space`, `advanceWhile` and `consumeLineBreakIfPresent`.
Reviewers: Duncan P. N. Exon Smith
Differential Revision: http://reviews.llvm.org/D9503
llvm-svn: 237314
|
|
|
|
|
|
|
|
|
|
|
|
| |
The TargetRegistry is just a namespace-like class, instantiated in one
place to use a range-based for loop. Instead, expose access to the
registry via a range-based 'targets()' function instead. This makes most
uses a bit awkward/more verbose - but eventually we should just add a
range-based find_if function which will streamline these functions. I'm
happy to mkae them a bit awkward in the interim as encouragement to
improve the algorithms in time.
llvm-svn: 237059
|
|
|
|
| |
llvm-svn: 236991
|
|
|
|
|
|
| |
previously causing a warning with MSVC about a compiler-generated local variable because TargetRegistry::begin() and end() are static member functions. NFC.
llvm-svn: 236990
|
|
|
|
|
|
|
| |
This was omitted from http://reviews.llvm.org/D9441
(the irony is that that was to detect omissions in something else)
llvm-svn: 236878
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D9441
llvm-svn: 236865
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit changes the 'skip' method in the 'KeyValueNode' class
to ensure that it doesn't dereference a null pointer when calling
the 'skip' method of its value child node. It also adds a unittest
that ensures that the crash doesn't occur.
This change is motivated by a patch that implements parsing
of YAML block scalars (http://reviews.llvm.org/D9503), as one
of the unittests in that patch triggered this problem.
llvm-svn: 236669
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mapping output.
This patch adds an optional 'flow' field to the MappingTrait
class so that yaml IO will be able to output flow mappings.
Reviewers: Justin Bogner
Differential Revision: http://reviews.llvm.org/D9450
llvm-svn: 236456
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes a bug where the YAML Output class emitted
a sequence of flow sequences without the '-' characters.
Before:
seq:
[ a, b ]
[ c, d ]
After:
seq:
- [ a, b ]
- [ c, d ]
Reviewers: Justin Bogner
Differential Revision: http://reviews.llvm.org/D9206
llvm-svn: 236329
|
|
|
|
|
|
|
|
|
| |
Patch from dexonsmith. The call to toInt() was calling compareTo() which
in some cases would call back to toInt(), creating an infinite loop.
Fixed by simplifying the logic in compareTo() to avoid the co-recursion.
llvm-svn: 236326
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The private constructor for ScaledNumber was using uint64_t instead of
DigitsT. This was preventing instantiations of ScaledNumber with
anything other than uint64_t types.
In implementing the tests, I ran into another issue. Operators >>= and
<<= did not have variants for accepting other ScaledNumber as the shift
argument. This is expected by the SCALED_NUMBER_BOP.
It makes no sense to allow shifting a ScaledNumber by another
ScaledNumber, so the patch includes two new templates for shifting
ScaledNumbers.
Reviewers: dexonsmith
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9350
llvm-svn: 236232
|
|
|
|
| |
llvm-svn: 236227
|
|
|
|
| |
llvm-svn: 236126
|
|
|
|
| |
llvm-svn: 236106
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current implementations could exhibit some behavior differences:
raw_fd_ostream: Whatever the underlying fd does with seek+write. In a normal
file, the write position would be back to the old offset.
raw_svector_ostream: The write position is always the end of the stream, so
after pwrite the write position would be the new end. This matches what OS_X
(all BSD?) do with a pwrite in a O_APPEND fd.
Given that we don't need that feature and don't use O_APPEND a lot in LLVM,
just disallow it.
I am open to suggestions on renaming pwrite to something else, but this fixes
the issue for now.
Thanks to Yaron Keren for reporting it.
llvm-svn: 235303
|
|
|
|
|
|
|
| |
This is a raw_ostream that also supports pwrite.
I will be used in a sec.
llvm-svn: 234895
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is generated using clang-tidy misc-use-override check.
This command was used:
tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \
-checks='-*,misc-use-override' -header-filter='llvm|clang' \
-j=32 -fix -format
http://reviews.llvm.org/D8925
llvm-svn: 234679
|
|
|
|
|
|
|
|
| |
We wrap __attribute((aligned)) for GCC 4.7 and __declspec(align) for
MSVC. The latter behaves weird in some contexts so this should be used
carefully.
llvm-svn: 233910
|