| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unlike scalar operations, we can perform vector operations on element types that
are smaller than the native integer types. We type-promote scalar operations if
they are smaller than a native type (e.g., i8 arithmetic is promoted to i32
arithmetic on Arm targets). This patch detects and removes type-promotions
within the reduction detection framework, enabling the vectorization of small
size reductions.
In the legality phase, we look through the ANDs and extensions that InstCombine
creates during promotion, keeping track of the smaller type. In the
profitability phase, we use the smaller type and ignore the ANDs and extensions
in the cost model. Finally, in the code generation phase, we truncate the result
of the reduction to allow InstCombine to rewrite the entire expression in the
smaller type.
This fixes PR21369.
http://reviews.llvm.org/D12202
Patch by Matt Simpson <mssimpso@codeaurora.org>!
llvm-svn: 246149
|
| |
|
|
|
|
|
|
| |
This patch fix the function GetTls for aarch64, where it assumes it
follows the x86_64 way where the TLS initial address is at the end
of TLS. Instead aarch64 set the TLS address as the thread pointer.
llvm-svn: 246148
|
| |
|
|
| |
llvm-svn: 246147
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
Constructor() : initializer(0) {}
template <typename T>
Constructor()
: initializer(0) {}
After:
Constructor() : initializer(0) {}
template <typename T>
Constructor() : initializer(0) {}
llvm-svn: 246146
|
| |
|
|
|
|
|
|
| |
... and move it into LoopUtils where it can be used by other passes, just like ReductionDescriptor. The API is very similar to ReductionDescriptor - that is, not very nice at all. Sorting these both out will come in a followup.
NFC
llvm-svn: 246145
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change allows the BlockGenerator to be reused in contexts where we want to
provide different/modified isl_ast_expressions, which are not only changed to
a different access relation than the original statement, but which may indeed
be different for each code-generated instance of the statement.
We ensure testing of this feature by moving Polly's support to import changed
access functions through a jscop file to use the BlockGenerators support for
generating arbitary access functions if provided.
This commit should not change the behavior of Polly for now. The diff is rather
large, but most changes are due to us passing the NewAccesses hash table through
functions. This style, even though rather verbose, matches what is done
throughout the BlockGenerator with other per-statement properties.
llvm-svn: 246144
|
| |
|
|
| |
llvm-svn: 246143
|
| |
|
|
|
|
|
|
|
|
|
| |
Use ISL to compute the loop trip count when scalar evolution is unable to do
so.
Contributed-by: Matthew Simpson <mssimpso@codeaurora.org>
Differential Revision: http://reviews.llvm.org/D9444
llvm-svn: 246142
|
| |
|
|
| |
llvm-svn: 246141
|
| |
|
|
| |
llvm-svn: 246140
|
| |
|
|
| |
llvm-svn: 246139
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Older OSX versions don't define NSOperatingSystemVersion, so building
lldb gets: error: unknown type name 'NSOperatingSystemVersion'
This patch fixes the build by having GetOSVersionNumbers return false if
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ < 101000, causing lldb to
behave the same as it did before the commit.
Reviewed by: jasonmolenda
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12396
llvm-svn: 246138
|
| |
|
|
|
|
|
|
|
| |
Globals in address spaces other than one may have 0 as a valid address,
so we should not assume that they can be null.
Reviewed by Philip Reames.
llvm-svn: 246137
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A release fence acts as a publication barrier for stores within the current thread to become visible to other threads which might observe the release fence. It does not require the current thread to observe stores performed on other threads. As a result, we can allow store-load and load-store forwarding across a release fence.
We do need to make sure that stores before the fence can't be eliminated even if there's another store to the same location after the fence. In theory, we could reorder the second store above the fence and *then* eliminate the former, but we can't do this if the stores are on opposite sides of the fence.
Note: While more aggressive then what's there, this patch is still implementing a really conservative ordering. In particular, I'm not trying to exploit undefined behavior via races, or the fact that the LangRef says only 'atomic' accesses are ordered w.r.t. fences.
Differential Revision: http://reviews.llvm.org/D11434
llvm-svn: 246134
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
pointers
When computing base pointers, we introduce new instructions to propagate the base of existing instructions which might not be bases. However, the algorithm doesn't make any effort to recognize when the new instruction to be inserted is the same as an existing one already in the IR. Since this is happening immediately before rewriting, we don't really have a chance to fix it after the pass runs without teaching loop passes about statepoints.
I'm really not thrilled with this patch. I've rewritten it 4 different ways now, but this is the best I've come up with. The case where the new instruction is just the original base defining value could be merged into the existing algorithm with some complexity. The problem is that we might have something like an extractelement from a phi of two vectors. It may be trivially obvious that the base of the 0th element is an existing instruction, but I can't see how to make the algorithm itself figure that out. Thus, I resort to the call to SimplifyInstruction instead.
Note that we can only adjust the instructions we've inserted ourselves. The live sets are still being tracked in side structures at this point in the code. We can't easily muck with instructions which might be in them. Long term, I'm really thinking we need to materialize the live pointer sets explicitly in the IR somehow rather than using side structures to track them.
Differential Revision: http://reviews.llvm.org/D12004
llvm-svn: 246133
|
| |
|
|
|
|
|
|
| |
This patch ensures that every analysis diagnostic produced by the vectorizer
will be printed if the loop has a vectorization hint on it. The condition has
also been improved to prevent printing when a disabling hint is specified.
llvm-svn: 246132
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dynamic library on the system given a basename
This will do things like,
given mylibrary,
return
libmylibrary.dylib on OSX
mylibrary.dll on Windows
and so on for other platforms
It is currently implemented for Windows, Darwin, and Linux. Other platforms should fill in accordingly
llvm-svn: 246131
|
| |
|
|
|
|
| |
instead of raw function pointers. NFC
llvm-svn: 246130
|
| |
|
|
|
|
|
|
|
|
| |
switch statement.
This is a one-line-change patch that moves the update to UnhandledWeights to the correct position: it should be updated for all clusters instead of just range clusters.
Differential Revision: http://reviews.llvm.org/D12391
llvm-svn: 246129
|
| |
|
|
|
|
|
|
|
| |
with multiple uses of feature map construction.
Note: We could make this a static function on TargetInfo if we
fix the x86 port needing to check the triple in an isolated case.
llvm-svn: 246128
|
| |
|
|
| |
llvm-svn: 246127
|
| |
|
|
| |
llvm-svn: 246126
|
| |
|
|
|
|
|
|
|
|
| |
As Sanjoy pointed out over in http://reviews.llvm.org/D11819, a switch on an icmp should always be able to become a branch instruction. This patch generalizes that notion slightly to prove that the default case of a switch is unreachable if the cases completely cover all possible bit patterns in the condition. Once that's done, the switch to branch conversion kicks in just fine.
Note: Duplicate case values are disallowed by the LangRef and verifier.
Differential Revision: http://reviews.llvm.org/D11995
llvm-svn: 246125
|
| |
|
|
|
|
|
|
| |
DeclarationName (because all ctor names are considered the same, and so on).
Reflect this in the type used as the lookup table key. As a side-effect, remove
one copy of the duplicated code used to compute the hash of the key.
llvm-svn: 246124
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Just `assert("string" && false)` instead of `assert("string" == NULL)`.
This avoid errors like
[...]\Core\SourceManager.cpp(647): warning C4130: '==' : logical operation on address of string constant
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12388
llvm-svn: 246123
|
| |
|
|
|
|
| |
this is going to see use shortly in unifying feature set construction.
llvm-svn: 246122
|
| |
|
|
|
|
| |
Address Eric's post-commit review of r245741. NFC.
llvm-svn: 246121
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Let NVPTX backend detect integer min and max patterns during isel and emit intrinsics that enable hardware support.
Reviewers: jholewinski, meheff, jingyue
Subscribers: arsenm, llvm-commits, meheff, jingyue, eliben, jholewinski
Differential Revision: http://reviews.llvm.org/D12377
llvm-svn: 246107
|
| |
|
|
|
|
|
|
|
|
| |
in ARMBaseInstrInfo.cpp,
Previously in isProfitableToIfCvt() in ARMBaseInstrInfo.cpp, the multiplication between an integer and a branch probability is done manually in an unsafe way that may lead to overflow. This patch corrects those cases by using BranchProbability's member function scale() to avoid overflow (which stores the intermediate result in int64).
Differential Revision: http://reviews.llvm.org/D12295
llvm-svn: 246106
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D11468
llvm-svn: 246105
|
| |
|
|
|
|
|
|
|
|
| |
statement.
Currently, when lowering switch statement and a new basic block is built for jump table / bit test header, the edge to this new block is not assigned with a correct weight. This patch collects the edge weight from all its successors and assign this sum of weights to the edge (and also the other fall-through edge). Test cases are adjusted accordingly.
Differential Revision: http://reviews.llvm.org/D12166#fae6eca7
llvm-svn: 246104
|
| |
|
|
|
|
| |
Expand the information on base pointers to include an example, the assumptions a collector is allowed to make, legal optimizations over gc.relocates, and the assumptions made by RewriteStatepointsForGC. This is the result of a recent conversation with folks from LLIC and the confusions that came to light therein.
llvm-svn: 246103
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This is the first step in a multi-step refactoring to move add_sanitizer_rt_symbols in the direction of other add_* functions in compiler-rt.
Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12386
llvm-svn: 246102
|
| |
|
|
| |
llvm-svn: 246101
|
| |
|
|
|
|
|
|
|
|
| |
Added a new class called DWARFDIE that contains a DWARFCompileUnit and DWARFDebugInfoEntry so that these items always stay together.
There were many places where we just handed out DWARFDebugInfoEntry pointers and then use them with a compile unit that may or may not be the correct one. Clients outside of DWARFCompileUnit and DWARFDebugInfoEntry should all be dealing with DWARFDIE instances instead of playing with DWARFCompileUnit/DWARFDebugInfoEntry pairs manually.
This paves to the way for some modifications that are coming for DWO.
llvm-svn: 246100
|
| |
|
|
| |
llvm-svn: 246099
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change `DIBuilder` always to produce 'distinct' nodes when creating
`DISubprogram` definitions. I measured a ~5% memory improvement in the
link step (of ld64) when using `-flto -g`.
`DISubprogram`s are used in two ways in the debug info graph.
Some are definitions, point at actual functions, and can't really be
shared between compile units. With full debug info, these point down at
their variables, forming uniquing cycles. These uniquing cycles are
expensive to link between modules, since all unique nodes that reference
them transitively need to be duplicated (see commit message for r244181
for more details).
Others are declarations, primarily used for member functions in the type
hierarchy. Definitions never show up there; instead, a definition
points at its corresponding declaration node.
I started by making all subprograms 'distinct'. However, that was too
big a hammer: memory usage *increased* ~5% (net increase vs. this patch
of ~10%) because the 'distinct' declarations undermine LTO type
uniquing. This is a targeted fix for the definitions (where uniquing is
an observable problem).
A couple of notes:
- There's an accompanying commit to update IRGen testcases in clang.
- ^ That's what I'm using to test this commit.
- In a follow-up, I'll change the verifier to require 'distinct' on
definitions and add an upgrade to `BitcodeReader`.
llvm-svn: 246098
|
| |
|
|
|
|
| |
add_compiler_rt_runtime.
llvm-svn: 246097
|
| |
|
|
|
|
|
| |
The gnuwin32 version of 'echo' appears to produce such files, causing a
test failure that only reproduced with gnuwin32.
llvm-svn: 246096
|
| |
|
|
|
|
|
|
| |
I stared at `false /*declaration*/` for quite some time before giving up
and checking the actual function to see what it meant. Replacing with
`/* isDefinition = */ false` to save myself effort later.
llvm-svn: 246095
|
| |
|
|
|
|
| |
An early error message is better than the "cannot select" alternative.
llvm-svn: 246094
|
| |
|
|
| |
llvm-svn: 246093
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Things of note:
- Other linkage types aren't handled yet. We'll figure it out with dynamic linking.
- Special LLVM globals are either ignored, or error out for now.
- TLS isn't supported yet (WebAssembly will have threads later).
- There currently isn't a syntax for alignment, I left it in a comment so it's easy to hook up.
- Undef is convereted to whatever the type's appropriate null value is.
- assert versus report_fatal_error: follow what other AsmPrinters do, and assert only on what should have been caught elsewhere.
llvm-svn: 246092
|
| |
|
|
| |
llvm-svn: 246091
|
| |
|
|
|
|
|
|
|
| |
A corresponding clang change will make it so that clang can consume part
of an assembler token. The assembler treats '.' as an identifier
character while clang does not, so it's view of the token stream is a
little different.
llvm-svn: 246089
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now we can parse code like this:
struct A {
int field;
};
int f(A o) {
__asm mov eax, o.field
}
Fixes PR19117.
llvm-svn: 246088
|
| |
|
|
| |
llvm-svn: 246087
|
| |
|
|
| |
llvm-svn: 246086
|
| |
|
|
| |
llvm-svn: 246085
|
| |
|
|
| |
llvm-svn: 246084
|
