Write __llvm_profile_write_buffer(), which uses the same logic as
__llvm_profile_write_file(), but writes directly to a provided `char*`
buffer instead.
<rdar://problem/15943240>
llvm-svn: 204499
It was misguided to plan to rely on __llvm_profile_write_buffer() in
__llvm_profile_write_file(). It's less complex to duplicate the writing
logic than to mmap the file.
Since it's here to stay, move `FILE*`-based writing logic into
InstrProfilingFile.c.
<rdar://problem/15943240>
llvm-svn: 204498
Move functions around to prepare for some other changes.
- Merge InstrProfilingExtras.h with InstrProfiling.h. There's no
benefit to having these split.
- Rename InstrProfilingExtras.c to InstrProfilingFile.c.
- Split actual buffer writing code out of InstrProfiling.c into
InstrProfilingBuffer.c.
- Drive-by corrections of a couple of header comments.
<rdar://problem/15943240>
llvm-svn: 204497
Read a raw binary profile that corresponds to a memory dump from the
runtime profile.
The test is a binary file generated from
cfe/trunk/test/Profile/c-general.c with the new compiler-rt runtime and
the matching text version of the input. It includes instructions on how
to regenerate.
<rdar://problem/15950346>
llvm-svn: 204496
This isn't a format we'll want to write out in practice, but moving it
to the writer library simplifies llvm-profdata and isolates it from
further changes to the format.
This also allows us to update the tests to not rely on the text output
format.
llvm-svn: 204489
This introduces the ProfileData library and updates llvm-profdata to
use this library for reading profiles. InstrProfReader is an abstract
base class that will be subclassed for both the raw instrprof data
from compiler-rt and the efficient instrprof format that will be used
for PGO.
llvm-svn: 204482
Summary:
VECTOR_SHUFFLE concatenates the vectors in an vectorwise fashion.
<0b00, 0b01> + <0b10, 0b11> -> <0b00, 0b01, 0b10, 0b11>
VSHF concatenates the vectors in a bitwise fashion:
<0b00, 0b01> + <0b10, 0b11> ->
0b0100 + 0b1110 -> 0b01001110
<0b10, 0b11, 0b00, 0b01>
We must therefore swap the operands to get the correct result.
The test case that discovered the issue was MultiSource/Benchmarks/nbench.
Reviewers: matheusalmeida
Reviewed By: matheusalmeida
Differential Revision: http://llvm-reviews.chandlerc.com/D3142
llvm-svn: 204480
The SReg_(32|64) register classes contain special registers in addition
to the numbered SGPRs. This can lead to machine verifier errors when
these register classes are used as sub-registers for SReg_128, since
SReg_128 only uses the numbered SGPRs.
Replacing SReg_(32|64) with SGPR_(32|64) fixes this problem, since
the SGPR_(32|64) register classes contain only numbered SGPRs.
Tests cases for this are comming in a later commit.
llvm-svn: 204474
For complex examples it may happen that we do not compute dependences. In this
case we do not want to crash, but just not detect parallel loops.
llvm-svn: 204470
from (external) compiler-rt build tree into LLVM/Clang build tree in
LLVM_BUILD_EXTERNAL_COMPILER_RT mode.
For instance, running
make asan -j12
in LLVM/Clang build tree will now build Clang, use it to configure
compiler-rt build tree, and invoke "make asan -j12" there. ASan runtime will
be built in the proper location, where Clang driver expects to find it.
Running
make check-asan
will build Clang, use it to configure compiler-rt build tree, build everything
there, and then run "make check-asan" in compiler-rt build tree using just-built
Clang and ASan runtime.
llvm-svn: 204463
Previous check relied on -DLLDB_DISABLE_PYTHON which was not valid as
it is defined in the top level LLDB Makefile which is included after the check.
If this check is moved after the inclusion of top level Makefile then
BUILT_SOURCES is not properly handled. So I am using the scheme present
in the Host/Makefile.
llvm-svn: 204459
...instead of a separate Requires for each one. This style was already
used in some places and seems more compact.
No behavioral change intended.
llvm-svn: 204452
Duncan P. N. Exon Smith