It was printing out nothing in this case.
llvm-objdump tries to disassemble sections a symbol at a time. In the case of a
fully stripped Mach-O executable the only symbol remaining in the (__TEXT,__text)
section is the special linker defined symbol __mh_execute_header . This
symbol is special in that while it is N_SECT symbol in the (__TEXT,__text)
its address is before the start of the (__TEXT,__text). It’s address is the
start of the __TEXT segment which is where the mach header is statically
linked. So the code in DisassembleMachO() needs to deal with this case specially.
rdar://26778273
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272837 91177308-0d34-0410-b5e6-96231b3b80d8
This patch makes CFLAA ignore non-pointer values, since we can now
sanely do that with the escaping/unknown attributes. Additionally,
StratifiedAttrs make more sense to sit on nodes than edges (since
they're properties of values, and ultimately end up on the nodes of
StratifiedSets). So, this patch puts said attributes on nodes.
Patch by Jia Chen.
Differential Revision: http://reviews.llvm.org/D21387
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272833 91177308-0d34-0410-b5e6-96231b3b80d8
Of course the assembly was right but because the opcode was MOVZWi it was
encoded as "movz w16, #65535, lsl #32" which is an unallocated encoding and
would go horribly wrong on a CPU.
No idea how this bug survived this long. It seems nobody is using that aspect
of patchpoints.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272831 91177308-0d34-0410-b5e6-96231b3b80d8
- We lacked a short unique identifier for a statistics, so I renamed the
current "Name" field that just contained the DEBUG_TYPE name of the
current file to DebugType and added a new "Name" field that contains
the C++ identifier of the statistic variable.
- Add the -stats-json option which outputs statistics in json format.
Differential Revision: http://reviews.llvm.org/D20995
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272826 91177308-0d34-0410-b5e6-96231b3b80d8
This allows us to emit native IR in Clang (next commit).
Also, update the intrinsic tests to show that codegen already knows how to handle
the IR that Clang will soon produce.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272806 91177308-0d34-0410-b5e6-96231b3b80d8
We would fail to validate the type of the tan function which would cause
downstream users of isValidProtoForLibFunc to assert.
This fixes PR28143.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272802 91177308-0d34-0410-b5e6-96231b3b80d8
Reverting due to assertion failure in
lib/CodeGen/SelectionDAG/InstrEmitter.cpp
This reverts commit r272792.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272799 91177308-0d34-0410-b5e6-96231b3b80d8
[DAG] Previously debug values would transfer debuginfo for the selected
start node for a replacement which allows for debug to be dropped.
Push debug value transfer to occur with node/value replacement in
SelectionDAG, remove now extraneous transfers of debug values.
This refixes PR9817 which was being incompletely checked in the
testsuite.
Reviewers: jyknight
Subscribers: dblaikie, llvm-commits
Differential Revision: http://reviews.llvm.org/D21037
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272792 91177308-0d34-0410-b5e6-96231b3b80d8
The error on clang-x86-win2008-selfhost is:
C:\buildbot\slave-config\clang-x86-win2008-selfhost\llvm\lib\Transforms\Vectorize\SLPVectorizer.cpp(955) : error C2248: 'llvm::slpvectorizer::BoUpSLP::ScheduleData' : cannot access private struct declared in class 'llvm::slpvectorizer::BoUpSLP'
C:\buildbot\slave-config\clang-x86-win2008-selfhost\llvm\lib\Transforms\Vectorize\SLPVectorizer.cpp(608) : see declaration of 'llvm::slpvectorizer::BoUpSLP::ScheduleData'
C:\buildbot\slave-config\clang-x86-win2008-selfhost\llvm\lib\Transforms\Vectorize\SLPVectorizer.cpp(337) : see declaration of 'llvm::slpvectorizer::BoUpSLP'
I reproduced this locally with both MSVC 2013 and MSVC 2015.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272772 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, there was a discrepancy between the population of function
passes in FPasses, and their invocation. Function passes specified on
the command line, after an optimizaton level was simply discared. This
fix PR27509.
Patch by Jesper Antonsson.
Differential Review: http://reviews.llvm.org/D20725
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272770 91177308-0d34-0410-b5e6-96231b3b80d8
This wasn't failing for me with clang as the compiler. I think GCC may
disagree with clang about whether a friend declaration introduces a
declaration in the enclosing namespace (or something).
Example error:
/home/uweigand/sandbox/buildbot/clang-s390x-linux/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:950:77: error: ‘llvm::raw_ostream& llvm::slpvectorizer::operator<<(llvm::raw_ostream&, const llvm::slpvectorizer::BoUpSLP::ScheduleData&)’ should have been declared inside ‘llvm::slpvectorizer’
const BoUpSLP::ScheduleData &SD) {
^
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272767 91177308-0d34-0410-b5e6-96231b3b80d8
This uses the "runImpl" approach to share code with the old PM.
Porting to the new PM meant abandoning the anonymous namespace enclosing
most of SLPVectorizer.cpp which is a bit of a bummer (but not a big deal
compared to having to pull the pass class into a header which the new PM
requires since it calls the constructor directly).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272766 91177308-0d34-0410-b5e6-96231b3b80d8
... instead of explicitly conditioning on NDEBUG. Also use an easier to
read conditional expression.
(Addresses post-commit review from David Blaikie.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272762 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This fixes two related bugs. First, the generic optimization passes
unfortunately generate negative constant offsets but the hardware treats
SOffset as an unsigned value.
Second, there is a hardware bug on SI and CI, where address clamping in MUBUF
instructions does not work correctly when SOffset is larger than the buffer
size. This patch works around this bug by never using SOffset.
An alternative workaround would be to do the clamping manually when SOffset
is too large, but generating the required code sequence during instruction
selection would be rather involved, and in any case the resulting code would
probably be worse.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96360
Reviewers: arsenm, tstellarAMD
Subscribers: arsenm, llvm-commits, kzhuravl
Differential Revision: http://reviews.llvm.org/D21326
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272761 91177308-0d34-0410-b5e6-96231b3b80d8
