| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libcall instead of just the call. This allows us to specify libcalls that return void.
LowerCallTo returns a pair with the return value of the call as the first
element and the chain associated with the return value as the second element. If
we lower a call that has a void return value, LowerCallTo returns an SDValue
with a NULL SDNode and the chain for the call. Thus makeLibCall by just
returning the first value makes it impossible for you to set up the chain so
that the call is not eliminated as dead code.
I also updated all references to makeLibCall to reflect the new return type.
llvm-svn: 188300
|
|
|
|
|
|
| |
DW_FORM_data4 as it is a section offset (fixes the coff/dwarf debug info statement locations)
llvm-svn: 188297
|
|
|
|
|
|
| |
relative item only when it's one of dw_from strp, sec_offset, ref_addr or op_call_ref instead of going by size.
llvm-svn: 188296
|
|
|
|
| |
llvm-svn: 188293
|
|
|
|
| |
llvm-svn: 188288
|
|
|
|
| |
llvm-svn: 188285
|
|
|
|
|
|
| |
I have moved this logic into clang and opt.
llvm-svn: 188281
|
|
|
|
|
|
|
|
|
|
| |
../lib/Target/X86/X86ISelLowering.cpp:9715:7: error: unused variable 'OpVT' [-Werror,-Wunused-variable]
EVT OpVT = Op0.getValueType();
^
../lib/Target/X86/X86ISelLowering.cpp:9763:14: error: unused variable 'NumElems' [-Werror,-Wunused-variable]
unsigned NumElems = VT.getVectorNumElements();
llvm-svn: 188269
|
|
|
|
| |
llvm-svn: 188268
|
|
|
|
|
|
| |
Lowering for SETCC.
llvm-svn: 188265
|
|
|
|
|
|
| |
The code now follows more deterministic path and makes the code more efficient and easier to maintain.
llvm-svn: 188264
|
|
|
|
| |
llvm-svn: 188259
|
|
|
|
|
|
| |
Before this, collectAttributes() was operating on a local object.
llvm-svn: 188254
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for COFF
Summary:
We need to do two things:
- Initialize BSSSection in MCObjectFileInfo::InitCOFFMCObjectFileInfo
- Teach TargetLoweringObjectFileCOFF::SelectSectionForGlobal what to do
with it
This fixes PR16861.
Reviewers: rnk
Reviewed By: rnk
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1361
llvm-svn: 188244
|
|
|
|
|
|
|
|
|
|
| |
CUs.
Currently only hashes the name of CUs and the names of any children,
but it's an obvious first step to show the framework. The testcase
should continue to be correct, however, as it's an empty TU.
llvm-svn: 188243
|
|
|
|
|
|
|
|
|
|
|
|
| |
to find loops if the From and To instructions were in the same block.
Refactor the code a little now that we need to fill to start the CFG-walking
algorithm with more than one starting basic block sometimes.
Special thanks to Andrew Trick for catching an error in my understanding of
natural loops in code review.
llvm-svn: 188236
|
|
|
|
| |
llvm-svn: 188233
|
|
|
|
| |
llvm-svn: 188232
|
|
|
|
|
|
|
| |
e.g. Use Ty->getPointerElementType()
instead of cast<PointerType>(Ty)->getElementType()
llvm-svn: 188223
|
|
|
|
| |
llvm-svn: 188219
|
|
|
|
|
|
|
|
|
| |
undefined and produce an error message instead as this is a non-relocatable
expression with X86 Mach-O.
rdar://8920876
llvm-svn: 188218
|
|
|
|
| |
llvm-svn: 188217
|
|
|
|
| |
llvm-svn: 188216
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
R600 doesn't need to do any scheduling on the SelectionDAG now that it
has a very good MachineScheduler. Also, using the VLIW SelectionDAG
scheduler was having a major impact on compile times. For example with
the phatk kernel here are the LLVM IR to machine code compile times:
With Sched::VLIW
Total Compile Time: 1.4890 Seconds (User + System)
SelectionDAG Instruction Scheduling: 1.1670 Seconds (User + System)
With Sched::Source
Total Compile Time: 0.3330 Seconds (User + System)
SelectionDAG Instruction Scheduling: 0.0070 Seconds (User + System)
The code ouput was identical with both schedulers. This may not be true
for all programs, but it gives me confidence that there won't be much
reduction, if any, in code quality by using Sched::Source.
llvm-svn: 188215
|
|
|
|
|
|
| |
C++ instead of c++.
llvm-svn: 188203
|
|
|
|
|
|
| |
filetype declaration.
llvm-svn: 188202
|
|
|
|
| |
llvm-svn: 188201
|
|
|
|
|
|
| |
has been finalized except for sizes and offsets. Update test accordingly.
llvm-svn: 188199
|
|
|
|
| |
llvm-svn: 188198
|
|
|
|
|
|
|
| |
We support this libcall on all platforms except for OpenBSD (See
lib/Codegen/StackProtector.cpp).
llvm-svn: 188193
|
|
|
|
|
|
|
| |
Do not generate new vector values for the same entries because we know that the incoming values
from the same block must be identical.
llvm-svn: 188185
|
|
|
|
|
|
|
|
|
| |
This fixes the incorrect implementation of iterating on file/directory
paths.
Differential Review: http://llvm-reviews.chandlerc.com/D1277
llvm-svn: 188183
|
|
|
|
| |
llvm-svn: 188176
|
|
|
|
| |
llvm-svn: 188171
|
|
|
|
| |
llvm-svn: 188169
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
curses.h). Finding these headers is next to impossible. For example, on
Debian systems libtinfo-dev provides the terminfo reading library we
want, but *not* term.h. For the header, you have to use libncurses-dev.
And libncursesw-dev provides a *different* term.h in a different
location!
These headers aren't worth it. We want two functions the signatures of
which are clearly spec'ed in sys-v and other documentation. Just declare
them ourselves and call them. This should fix some debian builders and
provide better support for "minimal" debian systems that do want color
autodetection.
llvm-svn: 188165
|
|
|
|
|
|
|
| |
For now this is restricted to fixed-length comparisons with a length
in the range [1, 256], as for memcpy() and MVC.
llvm-svn: 188163
|
|
|
|
| |
llvm-svn: 188162
|
|
|
|
| |
llvm-svn: 188161
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
library for color support detection. This still will use a curses
library if that is all we have available on the system. This change
tries to use a smaller subset of the curses library, specifically the
subset that is on some systems split off into a separate library. For
example, if you install ncurses configured --with-tinfo, a 'libtinfo' is
install that provides just the terminfo querying functionality. That
library is now used instead of curses when it is available.
This happens to fix a build error on systems with that library because
when we tried to link ncurses into the binary, we didn't pull tinfo in
as well. =]
It should also provide an easy path for supporting the NetBSD
libterminfo library, but as I don't have access to a NetBSD system I'm
leaving adding that support to those folks.
llvm-svn: 188160
|
|
|
|
|
|
|
|
| |
If the tail-callee and caller give the same bits via the same signext/zeroext
attribute then a tail-call should be allowed, since the extension has already
been done by the callee.
llvm-svn: 188159
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 188158
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Doing work in constructors is bad: this change suggests to
call SpecialCaseList::create(Path, Error) instead of
"new SpecialCaseList(Path)". Currently the latter may crash with
report_fatal_error, which is undesirable - sometimes we want to report
the error to user gracefully - for example, if he provides an incorrect
file as an argument of Clang's -fsanitize-blacklist flag.
Reviewers: pcc
Reviewed By: pcc
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1327
llvm-svn: 188156
|
|
|
|
|
|
|
|
|
|
| |
These functions used to assume that the lsb of an integer corresponds
to vector element 0, whereas for big-endian it's the other way around:
the msb is in the first element and the lsb is in the last element.
Fixes MultiSource/Benchmarks/mediabench/gsm/toast for z.
llvm-svn: 188155
|
|
|
|
|
|
|
|
|
|
|
| |
is actually an instrinsic that will not occur in libc. This list here
is not exhaustive but fixes the one places in test-suite where this occurs.
I have filed a bug against myself to research the full list and add them
to the array of such cases. In the future, actual stub generation will occur
in a later phase and we won't need this code because we will know at that time
during the compilation that in fact no helper function was even needed.
llvm-svn: 188149
|
|
|
|
| |
llvm-svn: 188148
|
|
|
|
|
|
| |
Added a test for shuffles using VPERM.
llvm-svn: 188147
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SROA-based analysis has enough information. This should work now that
both mem2reg *and* the SSAUpdater-based AllocaPromoter have been updated
to be able to promote the types of allocas that the SROA analysis
detects.
I've included tests for the AllocaPromoter that were only possible to
write once we fast-tracked promotable allocas without rewriting them.
This includes a test both for r187347 and r188145.
Original commit log for r187323:
"""
Now that mem2reg understands how to cope with a slightly wider set of uses of
an alloca, we can pre-compute promotability while analyzing an alloca for
splitting in SROA. That lets us short-circuit the common case of a bunch of
trivially promotable allocas. This cuts 20% to 30% off the run time of SROA for
typical frontend-generated IR sequneces I'm seeing. It gets the new SROA to
within 20% of ScalarRepl for such code. My current benchmark for these numbers
is PR15412, but it fits the general pattern of IR emitted by Clang so it should
be widely applicable.
"""
llvm-svn: 188146
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the more general set of patterns that are now handled by mem2reg and that we
can detect quickly while doing SROA's initial analysis. Notably, this allows it
to promote through no-op bitcast and GEP sequences. A core part of the
SSAUpdater approach is the ability to test whether a particular instruction is
part of the set being promoted. Testing this becomes significantly more complex
in the world where the operand to every load and store isn't the alloca itself.
I ended up using the approach of walking up the def-chain until we find the
alloca. I benchmarked this against keeping a set of pointer operands and
keeping a set of the loads and stores we care about, and this one seemed faster
although the difference was very small.
No test case yet because currently the rewriting always "fixes" the inputs to
not require this. The next patch which re-enables early promotion of easy cases
in SROA will include a test case that specifically exercises this aspect of the
alloca promoter.
llvm-svn: 188145
|
|
|
|
|
|
|
|
|
| |
our visiting datastructures in the AllocaPromoter/SSAUpdater path of
SROA. Also shift the order if clears around to be more consistent.
No functionality changed here, this is just a cleanup.
llvm-svn: 188144
|