| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
abomination.
For starters, this API is incredibly slow. In order to lookup the name
of a pass it must take a memory fence to acquire a pointer to the
managed static pass registry, and then potentially acquire locks while
it consults this registry for information about what passes exist by
that name. This stops the world of LLVMs in your process no matter
how little they cared about the result.
To make this more joyful, you'll note that we are preserving many passes
which *do not exist* any more, or are not even analyses which one might
wish to have be preserved. This means we do all the work only to say
"nope" with no error to the user.
String-based APIs are a *bad idea*. String-based APIs that cannot
produce any meaningful error are an even worse idea. =/
I have a patch that simply removes this API completely, but I'm hesitant
to commit it as I don't really want to perniciously break out-of-tree
users of the old pass manager. I'd rather they just have to migrate to
the new one at some point. If others disagree and would like me to kill
it with fire, just say the word. =]
llvm-svn: 227294
|
| |
|
|
| |
llvm-svn: 227291
|
| |
|
|
|
|
| |
member is a typedef (or other sugar) of a declaration.
llvm-svn: 227290
|
| |
|
|
|
|
|
| |
This commit creates infinite loop in DAG combine for in the LLVM test-suite
for aarch64 with mcpu=cylcone (just having neon may be enough to expose this).
llvm-svn: 227272
|
| |
|
|
| |
llvm-svn: 227256
|
| |
|
|
| |
llvm-svn: 227253
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch resolves part of PR21711 ( http://llvm.org/bugs/show_bug.cgi?id=21711 ).
The 'f3' test case in that report presents a situation where we have two 128-bit
stores extracted from a 256-bit source vector.
Instead of producing this:
vmovaps %xmm0, (%rdi)
vextractf128 $1, %ymm0, 16(%rdi)
This patch merges the 128-bit stores into a single 256-bit store:
vmovups %ymm0, (%rdi)
Differential Revision: http://reviews.llvm.org/D7208
llvm-svn: 227242
|
| |
|
|
|
|
|
|
|
| |
When lowering memcpy, memset or memmove, this assert checks whether the pointer
operands are in an address space < 256 which means "user defined address space"
on X86. However, this notion of "user defined address space" does not exist
for other targets.
llvm-svn: 227191
|
| |
|
|
|
|
|
| |
off of the MachineFunction or with the version that takes a
Function reference as an argument.
llvm-svn: 227185
|
| |
|
|
|
|
| |
(and remove an extraneous private).
llvm-svn: 227181
|
| |
|
|
|
| |
NB: Saving files after editing helps.
llvm-svn: 227178
|
| |
|
|
|
|
|
| |
when we didn't need the cast to the base class or the cached version
off of the subtarget.
llvm-svn: 227176
|
| |
|
|
| |
llvm-svn: 227173
|
| |
|
|
|
|
|
| |
subtarget and so doesn't need the TargetMachine or to access via
getSubtargetImpl. Update all callers.
llvm-svn: 227160
|
| |
|
|
|
|
| |
getSubtargetImpl.
llvm-svn: 227159
|
| |
|
|
|
|
| |
code.
llvm-svn: 227157
|
| |
|
|
|
|
| |
a subtarget.
llvm-svn: 227156
|
| |
|
|
| |
llvm-svn: 227121
|
| |
|
|
| |
llvm-svn: 227119
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
derived classes.
Since global data alignment, layout, and mangling is often based on the
DataLayout, move it to the TargetMachine. This ensures that global
data is going to be layed out and mangled consistently if the subtarget
changes on a per function basis. Prior to this all targets(*) have
had subtarget dependent code moved out and onto the TargetMachine.
*One target hasn't been migrated as part of this change: R600. The
R600 port has, as a subtarget feature, the size of pointers and
this affects global data layout. I've currently hacked in a FIXME
to enable progress, but the port needs to be updated to either pass
the 64-bitness to the TargetMachine, or fix the DataLayout to
avoid subtarget dependent features.
llvm-svn: 227113
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This change reverts the interesting parts of 226311 (and 227046). This change introduced two problems, and I've been convinced that an alternate approach is preferrable anyways.
The bugs were:
- Registery appears to require all users be within the same linkage unit. After this change, asking for "statepoint-example" in Transform/ would sometimes get you nullptr, whereas asking the same question in CodeGen would return the right GCStrategy. The correct long term fix is to get rid of the utter hack which is Registry, but I don't have time for that right now. 227046 appears to have been an attempt to fix this, but I don't believe it does so completely.
- GCMetadataPrinter::finishAssembly was being called more than once per GCStrategy. Each Strategy was being added to the GCModuleInfo multiple times.
Once I get time again, I'm going to split GCModuleInfo into the gc.root specific part and a GCStrategy owning Analysis pass. I'm probably also going to kill off the Registry. Once that's done, I'll move the new GCStrategyAnalysis and all built in GCStrategies into Analysis. (As original suggested by Chandler.) This will accomplish my original goal of being able to access GCStrategy from Transform/ without adding all of the builtin GCs to IR/.
llvm-svn: 227109
|
| |
|
|
|
|
|
|
|
|
|
| |
physical register that is described in a DBG_VALUE.
In the testcase the DBG_VALUE describing "p5" becomes unavailable
because the register its address is in is clobbered and we (currently)
aren't smart enough to realize that the value is rematerialized immediately
after the DBG_VALUE and/or is actually a stack slot.
llvm-svn: 227056
|
| |
|
|
| |
llvm-svn: 227035
|
| |
|
|
|
|
| |
Minor tweaks to whitespace formatting that I noticed was off. NFC.
llvm-svn: 227014
|
| |
|
|
|
|
|
|
|
|
|
| |
This fixes a regression introduced by r226816.
When replacing a splat shuffle node with a constant build_vector,
make sure that the new build_vector has a valid number of elements.
Thanks to Patrik Hagglund for reporting this problem and providing a
small reproducible.
llvm-svn: 227002
|
| |
|
|
|
|
| |
Should fix PR22305.
llvm-svn: 226969
|
| |
|
|
|
|
|
|
| |
- input_iterator
- define an operator->
- make constructors private were possible
llvm-svn: 226967
|
| |
|
|
|
|
|
|
| |
DIExpression::Operand, so we can write range-based for loops.
Thanks to David Blaikie for the idea.
llvm-svn: 226939
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This mostly reverts commit r222062 and replaces it with a new enum. At
some point this enum will grow at least for other MSVC EH personalities.
Also beefs up the way we were sniffing the personality function.
Previously we would emit the Itanium LSDA despite using
__C_specific_handler.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D6987
llvm-svn: 226920
|
| |
|
|
| |
llvm-svn: 226919
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: When trying to constant fold an FMA in the DAG, getNode()
fails to fold the FMA if an operand is not finite. In this case this
patch allows the constant folding if !TLI->hasFloatingPointExceptions()
Reviewers: resistor
Reviewed By: resistor
Subscribers: hfinkel, llvm-commits
Differential Revision: http://reviews.llvm.org/D6912
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 226901
|
| |
|
|
|
|
|
|
|
|
|
|
| |
v2: use getZExtValue
add missing break
codestyle
v3: add few more comments
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Matt Arsenault <Matthew.Arsenault@amd.com>
llvm-svn: 226880
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically, gc.result benefits from this greatly. Instead of:
gc.result.int.*
gc.result.float.*
gc.result.ptr.*
...
We now have a gc.result.* that can specialize to literally any type.
Differential Revision: http://reviews.llvm.org/D7020
llvm-svn: 226857
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a 2nd try at the same optimization as http://reviews.llvm.org/D6698.
That patch was checked in at r224611, but reverted at r225031 because it
caused a failure outside of the regression tests.
The cause of the crash was not recognizing consecutive stores that have mixed
source values (loads and vector element extracts), so this patch adds a check
to bail out if any store value is not coming from a vector element extract.
This patch also refactors the shared logic of the constant source and vector
extracted elements source cases into a helper function.
Differential Revision: http://reviews.llvm.org/D6850
llvm-svn: 226845
|
| |
|
|
|
|
|
|
|
|
|
| |
problems when inlining two calls to the same function from the same call site."
The underlying bug has been fixed in r226736 so there's no need to
workaround this anymore.
This reverts commit r220923.
llvm-svn: 226842
|
| |
|
|
|
|
| |
Addresses review feedback from Duncan.
llvm-svn: 226835
|
| |
|
|
|
|
|
|
|
|
|
| |
This solves PR22276.
Splats of constants would sometimes produce redundant shuffles, sometimes ridiculously so (see the PR for details). Fold these shuffles into BUILD_VECTORs early on instead.
Differential Revision: http://reviews.llvm.org/D7093
Fixed recommit of r226811.
llvm-svn: 226816
|
| |
|
|
| |
llvm-svn: 226814
|
| |
|
|
|
|
|
|
|
| |
This solves PR22276.
Splats of constants would sometimes produce redundant shuffles, sometimes ridiculously so (see the PR for details). Fold these shuffles into BUILD_VECTORs early on instead.
Differential Revision: http://reviews.llvm.org/D7093
llvm-svn: 226811
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The problem occurs when after vectorization we have type
<2 x i32>. This type is promoted to <2 x i64> and then requires
additional efforts for expanding loads and truncating stores.
I added EXPAND / TRUNCATE attributes to the masked load/store
SDNodes. The code now contains additional shuffles.
I've prepared changes in the cost estimation for masked memory
operations, it will be submitted separately.
llvm-svn: 226808
|
| |
|
|
| |
llvm-svn: 226806
|
| |
|
|
|
|
|
|
|
| |
Type MVT::i1 became legal in KNL, but store operation can't be narrowed to this type,
since the size of VT (1 bit) is not equal to its actual store size(8 bits).
Added a test provided by David (dag@cray.com)
llvm-svn: 226805
|
| |
|
|
| |
llvm-svn: 226767
|
| |
|
|
| |
llvm-svn: 226748
|
| |
|
|
|
|
|
| |
It can help with argument juggling on some targets, and is generally a good
idea.
llvm-svn: 226740
|
| |
|
|
|
|
|
|
|
| |
are only reading a dead superregister value
This was not necessary before as this case can only be detected when the
liveness analysis is at subregister level.
llvm-svn: 226733
|
| |
|
|
|
|
|
|
|
|
|
| |
This cleans up code and is more in line with the general philosophy of
modifying LiveIntervals through LiveIntervalAnalysis instead of changing
them directly.
This also fixes a case where SplitEditor::removeBackCopies() would miss
the subregister ranges.
llvm-svn: 226690
|
| |
|
|
|
|
|
|
| |
This cleans up code and is more in line with the general philosophy of
modifying LiveIntervals through LiveIntervalAnalysis instead of changing
them directly.
llvm-svn: 226687
|
| |
|
|
| |
llvm-svn: 226686
|
| |
|
|
|
|
|
|
| |
It hadn't gone through review yet, but was still on my local copy.
This reverts commit r226663
llvm-svn: 226665
|