| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 300155
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This seems like a much more natural API, based on Derek Schuff's
comments on r300015. It further hides the implementation detail of
AttributeList that function attributes come last and appear at index
~0U, which is easy for the user to screw up. git diff says it saves code
as well: 97 insertions(+), 137 deletions(-)
This also makes it easier to change the implementation, which I want to
do next.
llvm-svn: 300153
|
| |
|
|
|
|
| |
This typedef used to be conditional based on whether rvalue references were supported. Looks like it got left behind when we switched to always having rvalue references with c++11. I don't think it provides any value now.
llvm-svn: 300146
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
```
Compiling Attributes.cpp ...
../../../Attributes.cpp: In member function 'std::__1::pair<unsigned int, llvm::Optional<unsigned int> > llvm::AttributeSet::getAllocSizeArgs() const':
../../../Attributes.cpp:542:69: error: operands to ?: have different types 'std::__1::pair<unsigned int, llvm::Optional<unsigned int> >' and 'std::__1::pair<int, int>'
return SetNode ? SetNode->getAllocSizeArgs() : std::make_pair(0, 0);
^
../../../Attributes.cpp:543:1: error: control reaches end of non-void function [-Werror=return-type]
}
^
```
Differential Revision: https://reviews.llvm.org/D31981
llvm-svn: 300143
|
| |
|
|
|
|
|
|
| |
branch issue.
Differential Revision: http://reviews.llvm.org/D31350
llvm-svn: 300142
|
| |
|
|
| |
llvm-svn: 300139
|
| |
|
|
| |
llvm-svn: 300137
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Improve performance of argument list parsing with large numbers of IDs and
large numbers of arguments, by tracking a conservative range of indexes within
the argument list that might contain an argument with each ID. In the worst
case (when the first and last argument with a given ID are at the opposite ends
of the argument list), this still results in a linear-time walk of the list,
but it helps substantially in the common case where each ID occurs only once,
or a few times close together in the list.
This gives a ~10x speedup to clang's `test/Driver/response-file.c`, which
constructs a very large set of command line arguments and feeds them to the
clang driver.
Differential Revision: https://reviews.llvm.org/D30130
llvm-svn: 300135
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a followup patch I intend to introduce an additional dumping
mode which dumps a graphical representation of a class's layout.
In preparation for this, the text-based layout printer needs to
be split out from the graphical layout printer, and both need
to be able to use the same code for printing the intro and outro
of a class's definition (e.g. base class list, etc).
This patch does so, and in the process introduces a skeleton
definition for the graphical printer, while currently making
the graphical printer just print nothing.
NFC
llvm-svn: 300134
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the dumping of class definitions was very primitive,
and it made it hard to do more than the most trivial of output
formats when dumping. As such, we would only dump one line for
each field, and then dump non-layout items like nested types
and enums.
With this patch, we do a complete analysis of the object
hierarchy including aggregate types, bases, virtual bases,
vftable analysis, etc. The only immediately visible effects
of this are that a) we can now dump a line for the vfptr where
before we would treat that as padding, and b) we now don't
treat virtual bases that come at the end of a class as padding
since we have a more detailed analysis of the class's storage
usage.
In subsequent patches, we should be able to use this analysis
to display a complete graphical view of a class's layout including
recursing arbitrarily deep into an object's base class / aggregate
member hierarchy.
llvm-svn: 300133
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The test fails on Darwin because Fuzzer::DeathCallback (which calls
DumpCurrentUnit("crash-")) is called before DumpCurrentUnit("oom-") is
called in Fuzzer::RssLimitCallback. DeathCallback is transitively called
from __sanitizer_print_memory_profile.
This should fix the fuzzer bot that has been failing for a while:
http://lab.llvm.org:8080/green/job/libFuzzer/
llvm-svn: 300127
|
| |
|
|
|
|
|
|
| |
anything.
Should give a small compile time improvement.
llvm-svn: 300125
|
| |
|
|
|
|
|
|
| |
instruction.
Previously it tried to call SimplifyInstruction which doesn't know anything about alloca so defers to constant folding which also doesn't do anything with alloca. This results in wasted cycles making calls that won't do anything. Given the frequency with which this function is called this time adds up.
llvm-svn: 300118
|
| |
|
|
|
|
| |
Delete following conditional that is always true as a result.
llvm-svn: 300117
|
| |
|
|
|
|
|
| |
Insert a VReg_1 virtual register so the i1 workaround pass
can handle it.
llvm-svn: 300113
|
| |
|
|
|
|
|
|
|
| |
If workgroup size is known inform llvm about range returned by local
id and local size queries.
Differential Revision: https://reviews.llvm.org/D31804
llvm-svn: 300102
|
| |
|
|
|
|
|
|
|
|
| |
functions. NFCI.
This will make it easier to teach this code about the string table.
Differential Revision: https://reviews.llvm.org/D31828
llvm-svn: 300099
|
| |
|
|
|
|
|
|
| |
known bits using the LHS/RHS known bits it already acquired without recursing back into computeKnownBits.
This replicates the known bits and constant creation code from the single use case for these instructions and adds it here. The computeKnownBits and constant creation code for other instructions is now in the default case of the opcode switch.
llvm-svn: 300094
|
| |
|
|
|
|
|
|
| |
bits on both sides are known to be zero into a constant 0.
We already handled a superset check that included the known ones too and folded to a constant that may include ones. But it can also handle the case of no ones.
llvm-svn: 300093
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
As discussed in:
https://bugs.llvm.org/show_bug.cgi?id=32486
...the canonicalization of vector select to shufflevector does not hold up
when undef elements are present in the condition vector.
Try to make the undef handling clear in the code and the LangRef.
Differential Revision: https://reviews.llvm.org/D31980
llvm-svn: 300092
|
| |
|
|
|
|
| |
copies when bit width is larger than 64-bits.
llvm-svn: 300091
|
| |
|
|
|
|
|
|
|
| |
The use of a DenseMap in precomputeTriangleChains does not cause
non-determinism, even though it is iterated over, as the only thing the
iteration does is to insert entries into a new DenseMap, which is not iterated.
Comment only change.
llvm-svn: 300088
|
| |
|
|
|
|
| |
cascaded ifs on opcode. NFC
llvm-svn: 300085
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
instruction that has multiple uses, if we know all the bits for the demanded bits for this context we can go ahead and create a constant.
Currently if we reach an instruction with multiples uses we know we can't do any optimizations to that instruction itself since we only have the demanded bits for one of the users. But if we know all of the bits are zero/one for that one user we can still go ahead and create a constant to give to that user.
This might then reduce the instruction to having a single use and allow additional optimizations on the other path.
This picks up an additional case that r300075 didn't catch.
Differential Revision: https://reviews.llvm.org/D31552
llvm-svn: 300084
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current heuristic is triggered on `InFlightCount > BufferLimit`
which isn't really helpful on in-order cores where BufferLimit is zero.
Note that we already get latency hiding effects for in order cores
by instructions staying in the pending queue on stalls; The additional
latency scheduling heuristics only have minimal effects after that while
occasionally increasing register pressure too much resulting in extra
spills.
My motivation here is additional spills/reloads ending up in a loop in
464.h264ref / BlockMotionSearch function resulting in a 4% overal
regression on an in order core. rdar://30264380
llvm-svn: 300083
|
| |
|
|
|
|
| |
instructions with multiple uses out to a separate method. NFCI
llvm-svn: 300082
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added support for VI:
- s_endpgm_saved
- s_wakeup
- s_rfe_restore_b64
- v_perm_b32
Enabled for VI:
- v_mov_fed_b32
- v_mov_fed_b32_e64
See bug 32593: https://bugs.llvm.org//show_bug.cgi?id=32593
Reviewers: artem.tamazov, vpykhtin
Differential Revision: https://reviews.llvm.org/D31931
llvm-svn: 300076
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
below the highest demanded bit can be simplified
If we are adding/subtractings 0s below the highest demanded bit we can just use the other operand and remove the operation.
My primary motivation is observing that we can call ShrinkDemandedConstant for the add/sub and create a 0 constant, rather than removing the add completely. In the case I saw, we modified the constant on an add instruction to a 0, but the add is not put into the worklist. So we didn't revisit it until the next InstCombine iteration. This caused an IR modification to remove add and a subsequent iteration to be ran.
With this change we get bypass the add in the first iteration and prevent the second iteration from changing anything.
Differential Revision: https://reviews.llvm.org/D31120
llvm-svn: 300075
|
| |
|
|
|
|
|
|
|
|
| |
Fixed bug 32565: https://bugs.llvm.org//show_bug.cgi?id=32565
Reviewers: vpykhtin
Differential Revision: https://reviews.llvm.org/D31820
llvm-svn: 300073
|
| |
|
|
|
|
| |
This fixes the failing WebAssemblyLowerEmscriptenEHSjLj tests
llvm-svn: 300072
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Corrected encoding of V_MQSAD_U32_U8 for CI
See bug 32552: https://bugs.llvm.org//show_bug.cgi?id=32552
Reviewers: vpykhtin
Differential Revision: https://reviews.llvm.org/D31810
llvm-svn: 300070
|
| |
|
|
| |
llvm-svn: 300069
|
| |
|
|
|
|
|
|
|
|
|
|
| |
One potential way to make InstCombine (very slightly?) faster is to recycle instructions
when possible instead of creating new ones. It's not explicitly stated AFAIK, but we don't
consider this an "InstSimplify". We could, however, make a new layer to house transforms
like this if that makes InstCombine more manageable (just throwing out an idea; not sure
how much opportunity is actually here).
Differential Revision: https://reviews.llvm.org/D31863
llvm-svn: 300067
|
| |
|
|
|
|
|
|
|
|
| |
Fixed bug 28227: https://bugs.llvm.org//show_bug.cgi?id=28227
Reviewers: vpykhtin
Differential Revision: https://reviews.llvm.org/D31808
llvm-svn: 300066
|
| |
|
|
| |
llvm-svn: 300063
|
| |
|
|
|
|
|
|
|
|
|
|
| |
On FreeBSD backtrace is not part of libc and depends on libexecinfo
being available. Instead of using manual checks we can use the builtin
CMake module FindBacktrace.cmake to detect availability of backtrace()
in a portable way.
Patch By: Alex Richardson
Differential Revision: https://reviews.llvm.org/D27143
llvm-svn: 300062
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In getEntryCost(), make the scalar type for a compare instruction that of the
operands, not i1. This is needed in order to call getCmpSelInstrCost() for a
compare in a sensible way, the same way as the LoopVectorizer does.
New test: test/Transforms/SLPVectorizer/SystemZ/SLP-cmp-cost-query.ll
Review: Matthew Simpson
https://reviews.llvm.org/D31601
llvm-svn: 300061
|
| |
|
|
|
|
| |
on DenseMap iteration order.
llvm-svn: 300060
|
| |
|
|
|
|
| |
No functionality change intended.
llvm-svn: 300059
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The cost for a branch after vectorization is very different depending on if
the vectorizer will if-convert the block (branch is eliminated), or if
scalarized and predicated blocks will be produced (branch duplicated before
each block). There is also the case of remaining scalar branches, such as the
back-edge branch.
This patch handles these cases differently with TTI based cost estimates.
Review: Matthew Simpson
https://reviews.llvm.org/D31175
llvm-svn: 300058
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: [GlobalISel][X86] support G_CONSTANT selection. Add regbank select tests.
Reviewers: zvi, guyblank
Reviewed By: guyblank
Subscribers: llvm-commits, dberris, rovka, kristof.beyls
Differential Revision: https://reviews.llvm.org/D31974
llvm-svn: 300057
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since SystemZ supports vector element load/store instructions, there is no
need for extracts/inserts if a vector load/store gets scalarized.
This patch lets Target specify that it supports such instructions by means of
a new TTI hook that defaults to false.
The use for this is in the LoopVectorizer getScalarizationOverhead() method,
which will with this patch produce a smaller sum for a vector load/store on
SystemZ.
New test: test/Transforms/LoopVectorize/SystemZ/load-store-scalarization-cost.ll
Review: Adam Nemet
https://reviews.llvm.org/D30680
llvm-svn: 300056
|
| |
|
|
|
|
|
|
|
|
| |
Fix for bug 28159: https://bugs.llvm.org//show_bug.cgi?id=28159
Reviewers: vpykhtin, arsenm
Differential Revision: https://reviews.llvm.org/D31595
llvm-svn: 300055
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
getArithmeticInstrCost(), getShuffleCost(), getCastInstrCost(),
getCmpSelInstrCost(), getVectorInstrCost(), getMemoryOpCost(),
getInterleavedMemoryOpCost() implemented.
Interleaved access vectorization enabled.
BasicTTIImpl::getCastInstrCost() improved to check for legal extending loads,
in which case the cost of the z/sext instruction becomes 0.
Review: Ulrich Weigand, Renato Golin.
https://reviews.llvm.org/D29631
llvm-svn: 300052
|
| |
|
|
| |
llvm-svn: 300051
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Remove checks for basic blocks.
Reviewers: vpykhtin, rampitec, arsenm
Subscribers: kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye
Differential Revision: https://reviews.llvm.org/D31935
llvm-svn: 300040
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change is basically relative to D31136, where I initially wanted to
implement some relocations handling optimization which shows it can give
significant boost. Though even without any caching algorithm looks
code can have some cleanup at first.
Refactoring separates out code for taking symbol address, used in relocations
computation.
Differential revision: https://reviews.llvm.org/D31747
llvm-svn: 300039
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Dead basic blocks may be forming a loop, for which SSA form is
fulfilled, but with a circular def-use chain. LoadCombine could
enter an infinite loop when analysing such dead code. This patch
solves the problem by simply avoiding to analyse all basic blocks
that aren't forward reachable, from function entry, in LoadCombine.
Fixes https://bugs.llvm.org/show_bug.cgi?id=27065
Reviewers: mehdi_amini, chandlerc, grosser, Bigcheese, davide
Reviewed By: davide
Subscribers: dberlin, zzheng, bjope, grandinj, Ka-Ka, materi, jholewinski, llvm-commits, mzolotukhin
Differential Revision: https://reviews.llvm.org/D31032
llvm-svn: 300034
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and to expose a handle to represent the actual case rather than having
the iterator return a reference to itself.
All of this allows the iterator to be used with common STL facilities,
standard algorithms, etc.
Doing this exposed some missing facilities in the iterator facade that
I've fixed and required some work to the actual iterator to fully
support the necessary API.
Differential Revision: https://reviews.llvm.org/D31548
llvm-svn: 300032
|
| |
|
|
|
|
| |
code. NFC
llvm-svn: 300030
|