| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
missing barcelona CPU which that test uncovered, and remove the 32-bit
x86 CPUs which I really wasn't prepared to audit and test thoroughly.
If anyone wants to clean up the 32-bit only x86 CPUs, go for it.
Also, if anyone else wants to try to de-duplicate the AMD CPUs, that'd
be cool, but from the looks of it wouldn't save as much as it did for
the Intel CPUs.
llvm-svn: 223774
|
| |
|
|
| |
llvm-svn: 223773
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Instructions of the form [ADD Rd, pc, #imm] are manually aliased
in processInstruction() to use ADR. To accomodate this, mod_imm handling
had to be tweaked a bit. Turns out it was the manual aliasing that must
be tweaked to accommodate mod_imms instead. More information about the
parsed instruction is available at the point where processInstruction()
is invoked, which makes it easier to detect a mod_imm at that point rather
than trying to detect a potential alias when a mod_imm is being prepped.
Added a test case and fixed some white spaces as well.
llvm-svn: 223772
|
| |
|
|
| |
llvm-svn: 223771
|
| |
|
|
| |
llvm-svn: 223770
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Notably, this adds simple micro-architecture names for the Intel CPU
variants, and defines the old 'core'-based names as aliases. GCC has
started to simplify their documented interface to use these names as
well, so it seems like we can start to converge on a consistent pattern.
I'd appreciate Intel double checking the entries that aren't yet
documented widely, especially Atom (Bonnell and Silvermont), Knights
Landing, and Skylake. But this change shouldn't break any existing
users.
Also, ran clang-format to re-format this code and it actually worked
(modulo a tiny bug) so hopefully we can start to stop thinking about
formatting this stuff.
llvm-svn: 223769
|
| |
|
|
| |
llvm-svn: 223768
|
| |
|
|
|
|
|
|
|
|
|
| |
Removed some duplicate test cases from the file /test/Transforms/InstCombine/shift.ll.
test54 and test57 were duplicates of each other.
test55 and test58 were duplicates of each other.
(Removed test57 and test58)
llvm-svn: 223767
|
| |
|
|
|
|
|
|
| |
There are still a vast range of improvements that can be done to this,
but it seems like an ok initial version. Suggestions or patches are
highly welcome.
llvm-svn: 223766
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Remove setting of default style, this way is not recommended and
means that all the settings have to be duplicated to demonstrate the
c-add-style method which is a much better way of doing it.
Remove the modified date as it is better stored in SVN.
Tweak a few style parameters to make them conform to the actual LLVM
style.
llvm-svn: 223765
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
integer and "element insertion" into a store of an integer into actual
element extraction, element insertion, and vector loads and stores.
Previously various parts of LLVM (including instcombine itself) would
introduce integer loads and stores into the code as a way of opaquely
loading and storing "bits". In some cases (such as a memcpy of
std::complex<float> object) we will eventually end up using those bits
in non-integer types. In order for SROA to effectively promote the
allocas involved, it splits these "store a bag of bits" integer loads
and stores up into the constituent parts. However, for non-alloca loads
and tsores which remain, it uses integer math to recombine the values
into a large integer to load or store.
All of this would be "fine", except that it forces LLVM to go through
integer math to combine and split up values. While this makes perfect
sense for integers (and in fact is critical for bitfields to end up
lowering efficiently) it is *terrible* for non-integer types, especially
floating point types. We have a much more canonical way of representing
the act of concatenating the bits of two SSA values in LLVM: a vector
and insertelement. This patch teaching InstCombine to use this
representation.
With this patch applied, LLVM will no longer introduce integer math into
the critical path of every loop over std::complex<float> operations such
as those that make up the hot path of ... oh, most HPC code, Eigen, and
any other heavy linear algebra library.
For the record, I looked *extensively* at fixing this in other parts of
the compiler, but it just doesn't work:
- We really do want to canonicalize memcpy and other bit-motion to
integer loads and stores. SSA values are tremendously more powerful
than "copy" intrinsics. Not doing this regresses massive amounts of
LLVM's scalar optimizer.
- We really do need to split up integer loads and stores of this form in
SROA or every memcpy of a trivially copyable struct will prevent SSA
formation of the members of that struct. It essentially turns off
SROA.
- The closest alternative is to actually split the loads and stores when
partitioning with SROA, but this has all of the downsides historically
discussed of splitting up loads and stores -- the wide-store
information is fundamentally lost. We would also see performance
regressions for bitfield-heavy code and other places where the
integers aren't really intended to be split without seemingly
arbitrary logic to treat integers totally differently.
- We *can* effectively fix this in instcombine, so it isn't that hard of
a choice to make IMO.
Differential Revision: http://reviews.llvm.org/D6548
llvm-svn: 223764
|
| |
|
|
|
|
|
|
| |
This is a revert of r223521 in spirit, if not in content. I am not
sure why declarations ended up in LazilyLinkGlobalValues in the first
place; that will take some more investigation.
llvm-svn: 223763
|
| |
|
|
| |
llvm-svn: 223762
|
| |
|
|
|
|
| |
No functional change.
llvm-svn: 223761
|
| |
|
|
|
|
| |
parity with F32 and F64.
llvm-svn: 223760
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r223753. It broke the Green Dragon build for a few
hours:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_build/2259/
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_build/2259/consoleFull#43901905849ba4694-19c4-4d7e-bec5-911270d8a58c
I suspect `clang-tools-extra` just needs a follow-up for an API change,
but I'm not the right one to look into it.
llvm-svn: 223759
|
| |
|
|
| |
llvm-svn: 223758
|
| |
|
|
|
|
|
|
|
|
|
| |
This handles the simplest case for mov -> push conversion:
1. x86-32 calling convention, everything is passed through the stack.
2. There is no reserved call frame.
3. Only registers or immediates are pushed, no attempt to combine a mem-reg-mem sequence into a single PUSHmm.
Differential Revision: http://reviews.llvm.org/D6503
llvm-svn: 223757
|
| |
|
|
|
|
|
| |
The commit is identical except a reference to `GV' should have been to
`GVal'.
llvm-svn: 223756
|
| |
|
|
|
|
| |
This reverts commit r223754. I've upset the buildbots.
llvm-svn: 223755
|
| |
|
|
|
|
|
|
|
| |
Don't assume that the forward referenced entity was of the same
global-kind as the new entity.
This fixes PR21779.
llvm-svn: 223754
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
For files named by -fmodule-map-file=, and files found by 'extern module'
directives, this flag specifies that we should resolve filenames relative to
the current working directory rather than relative to the directory in which
the module map file resides. This is aimed at fixing path handling, in
particular for relative -I paths, when building modules that represent
components of the current project (rather than libraries installed on the
current system, which the current project has as dependencies, where we'd
typically expect the module map files to be looked up implicitly).
llvm-svn: 223753
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Test Plan: Connect to a remote implementing the platform protocol (ds2 in this case), run `platform process list` and see processes being displayed.
Reviewers: vharron, tfiala, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6571
llvm-svn: 223752
|
| |
|
|
| |
llvm-svn: 223751
|
| |
|
|
| |
llvm-svn: 223750
|
| |
|
|
|
|
| |
HostInfo::GetOSKernelDescription.
llvm-svn: 223737
|
| |
|
|
| |
llvm-svn: 223733
|
| |
|
|
| |
llvm-svn: 223732
|
| |
|
|
| |
llvm-svn: 223731
|
| |
|
|
| |
llvm-svn: 223730
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unbreak bots.
CodeGen/PowerPC/vsx-p8.ll was failing.
'+power8-vector' is not a recognized feature for this target (ignoring feature)
llvm/test/CodeGen/PowerPC/vsx-p8.ll:33:14: error: expected string not found in input
; CHECK-REG: lxvw4x 34, 0, 3
^
<stdin>:50:2: note: scanning from here
.align 3
^
<stdin>:61:2: note: possible intended match here
lvx 3, 0, 3
^
llvm-svn: 223729
|
| |
|
|
|
|
|
|
| |
Geo-mean performance improvement of 0.2% (-0.3% - 0.9% @ 95% CI).
Differential Revision: http://reviews.llvm.org/D6569
llvm-svn: 223728
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The aggressive anti-dep breaker, used by the PowerPC backend during post-RA
scheduling (but is available to all targets), did not handle early-clobber MI
operands (at all). When constructing the list of available registers for the
replacement of some def operand, check the using instructions, and remove
registers assigned to early-clobbered defs from the set.
Fixes PR21452.
llvm-svn: 223727
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
elements
This particularly helps the fidelity of ASan reports (which can occur
even in these examples - if, for example, one uses placement new over a
buffer of insufficient size - now ASan will correctly identify which
member's initialization went over the end of the buffer).
This doesn't cover all types of members - more coming.
llvm-svn: 223726
|
| |
|
|
|
|
|
| |
and rearrange the prologue source location hack to immediately
after it.
llvm-svn: 223725
|
| |
|
|
|
|
| |
complain that the contained modules are defined twice.
llvm-svn: 223724
|
| |
|
|
|
|
|
|
| |
This reverts commit r223455. It's been succesfully argued that
-fexceptions (at the driver level) is a misnomer and has little to do
with -fobjc-exceptions.
llvm-svn: 223723
|
| |
|
|
| |
llvm-svn: 223722
|
| |
|
|
| |
llvm-svn: 223721
|
| |
|
|
|
|
| |
have encodings.
llvm-svn: 223720
|
| |
|
|
|
|
|
|
| |
This fixes an issue with ScheduleDAGInstrs::buildSchedGraph
where stores without an underlying object would not be added
as a predecessor to the current BarrierChain.
llvm-svn: 223717
|
| |
|
|
|
|
| |
Suggested in http://reviews.llvm.org/D6547.
llvm-svn: 223715
|
| |
|
|
|
|
|
| |
They too were fixed by r223185, despite the commit message saying otherwise.
Add a test that makes sure they don't regress.
llvm-svn: 223714
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Such a persisted version is equivalent to evaluating the value via the expression evaluator, and holding on to the $n result of the expression, except this API can be used on SBValues that do not obviously come from an expression (e.g. are the result of a memory lookup)
Expose this via SBValue::Persist() in our public API layer, and ValueObject::Persist() in the lldb_private layer
Includes testcase
Fixes rdar://19136664
llvm-svn: 223711
|
| |
|
|
|
|
| |
forms, mask, and vitpack instructions and patterns.
llvm-svn: 223710
|
| |
|
|
|
|
|
|
| |
This change activates FeatureVSX for Power 7 and Power 8 in PPC.td.
http://reviews.llvm.org/D6570
llvm-svn: 223709
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GCC accepts 'cc' as an alias for 'cr0', and we need to do the same when
processing inline asm constraints. This had previously been implemented using a
non-allocatable register, named 'cc', that was listed as an alias of 'cr0', but
the infrastructure does not seem to support this properly (neither the register
allocator nor the scheduler properly accounts for the alias). Instead, we can
just process this as a naming alias inside of the inline asm
constraint-processing code, so we'll do that instead.
There are two regression tests, one where the post-RA scheduler did the wrong
thing with the non-allocatable alias, and one where the register allocator did
the wrong thing. Fixes PR21742.
llvm-svn: 223708
|
| |
|
|
|
|
|
| |
Includes a new test case since none of the existing tests were hitting
this code path.
llvm-svn: 223705
|
| |
|
|
| |
llvm-svn: 223704
|
| |
|
|
| |
llvm-svn: 223702
|