Zero is used by BlockFrequencyInfo as a special "don't know" value. It also
causes a sink for frequencies as you can't ever get off a zero frequency with
more multiplies.
This recovers a 10% regression on MultiSource/Benchmarks/7zip. A zero frequency
was propagated into an inner loop causing excessive spilling.
PR16402.
llvm-svn: 184584
in the "parent" thread, when we are using CrashRecoveryContext::RunSafelyOnThread.
When using CrashRecoveryContext::RunSafelyOnThread, we would set a CrashRecoveryContextImpl* to a thread-local variable
for the "child" thread, but CrashRecoveryContext would erroneously clear it in the "parent" thread.
The result was that if CrashRecoveryContext::RunSafelyOnThread was called again in the "child" thread it would mess up
crash-recovery for its parent.
A test for this will be added in the clang repository.
rdar://14204560
llvm-svn: 184380
This ports a missing feature from PathV1.h. I am not sure how to test this
with the regular infrastructure, but an Apple bot should check this when
r183985 is reapplied.
llvm-svn: 184119
This broke for example the 'not' utility, if a directory called
'FileCheck' is executable and in the path before the actual 'FileCheck'.
This patch steals the implementation of the "old" PathV1 canExecute
implementation:
- checks for R_OK (file readable): this is necessary for executing
scripts; we should not regress here unless we have good reasons
- checks for S_ISREG; if we want to get rid of this, we'd need to
change all callers who already made the assumption when depending
on Path V1.
llvm-svn: 184074
It looks like clang-tools-extra/unittests/cpp11-migrate/TransformTest.cpp
depends on the behaviour of the old one on Windows. Maybe a difference
between GetCurrentDirectoryA and GetCurrentDirectoryW?
llvm-svn: 184009
Execute's Data parameter is now optional, so we won't allocate memory
for it on Windows and we'll close the process handle.
The Unix code should probably do something similar to avoid accumulation
of zombie children that haven't been waited on.
Tested on Linux and Windows.
llvm-svn: 183906
It was only used to implement ExecuteAndWait and ExecuteNoWait. Expose just
those two functions and make Execute and Wait implementations details.
llvm-svn: 183864
`typeinfo for llvm:🆑:GenericOptionValue').
Remove an "anchor" method for an abstract class. (This does not
increase the number of vtables.)
llvm-svn: 183830
For ARM on linux we use /proc/cpuinfo to detect the host CPU's features.
Linux derives these values without ever looking at the vendor of the
specific CPU implementation. Hence, it adds little value, if we parse
the output of /proc/cpuinfo only for certain vendors.
This patch enables us to derive the correct feature flags e.g. for Qualcomm
CPUs.
llvm-svn: 183790
It will be tested in the next commit which moves another user to identify_magic.
Original message:
Fix an out of bounds array access.
We were looking at Magic[5] without checking Length. Since this path would not
return unless Length >= 18 anyway, just move the >= 18 check up.
llvm-svn: 183753
We were looking at Magic[5] without checking Length. Since this path would not
return unless Length >= 18 anyway, just move the >= 18 check up.
llvm-svn: 183666
This is needed in clang so one can check if the object needs the
destructor called after its memory was freed. This is useful when
creating many APInt/APFloat objects with placement new, where the
overhead of tracking the pointers for cleanup is significant.
llvm-svn: 183100
There was exactly one caller using this API right, the others were relying on
specific behavior of the default implementation. Since it's too hard to use it
right just remove it and standardize on the default behavior.
Defines away PR16132.
llvm-svn: 182636
This patch builds on some existing code to do CFG reconstruction from
a disassembled binary:
- MCModule represents the binary, and has a list of MCAtoms.
- MCAtom represents either disassembled instructions (MCTextAtom), or
contiguous data (MCDataAtom), and covers a specific range of addresses.
- MCBasicBlock and MCFunction form the reconstructed CFG. An MCBB is
backed by an MCTextAtom, and has the usual successors/predecessors.
- MCObjectDisassembler creates a module from an ObjectFile using a
disassembler. It first builds an atom for each section. It can also
construct the CFG, and this splits the text atoms into basic blocks.
MCModule and MCAtom were only sketched out; MCFunction and MCBB were
implemented under the experimental "-cfg" llvm-objdump -macho option.
This cleans them up for further use; llvm-objdump -d -cfg now generates
graphviz files for each function found in the binary.
In the future, MCObjectDisassembler may be the right place to do
"intelligent" disassembly: for example, handling constant islands is just
a matter of splitting the atom, using information that may be available
in the ObjectFile. Also, better initial atom formation than just using
sections is possible using symbols (and things like Mach-O's
function_starts load command).
This brings two minor regressions in llvm-objdump -macho -cfg:
- The printing of a relocation's referenced symbol.
- An annotation on loop BBs, i.e., which are their own successor.
Relocation printing is replaced by the MCSymbolizer; the basic CFG
annotation will be superseded by more related functionality.
llvm-svn: 182628
Benjamin Kramer