All Intel CPUs since Yonah look a lot alike, at least at the granularity
of the scheduling models. We can add more accurate models for
processors that aren't Sandy Bridge if required. Haswell will probably
need its own.
The Atom processor and anything based on NetBurst is completely
different. So are the non-Intel chips.
llvm-svn: 178080
This will be used to factor out some uses of magic number operand offsets
inside Clang where these fields were updated in an effort to resolve forward
declarations/circular references.
llvm-svn: 178078
As suggested by Bill Schmidt (in reviewing r178067), use the real register
number bit lengths (which is self-documenting, and prevents using illegal
numbers), and set only the relevant bits in HWEncoding (which defaults to 0).
No functionality change intended.
llvm-svn: 178077
The algorithm to access an item in a __NSArrayM was not reacting properly to deletions
The fix is to use a smarter formula that accounts for items shifting and the resulting notion of offsets in the table
llvm-svn: 178076
As pointed out by Richard Sandiford, my recent updates to the register
scavenger broke targets that use custom spilling (because the new code assumed
that if there were no valid spill slots, than spilling would be impossible).
I don't have a test case, but it should be possible to create one for Thumb 1,
Mips 16, etc.
llvm-svn: 178073
As pointed out by Jakob, we don't need to maintain a separate
register-numbering table. Instead we should let TableGen generate the table for
us from the information (already present) in PPCRegisterInfo.td.
TRI->getEncodingValue is now used to access register-encoding values.
No functionality change intended.
llvm-svn: 178067
Now that the register scavenger can support multiple spill slots, and PEI can
use virtual-register-based scavenging for multiple simultaneous registers, we
can use a virtual register for the transfer register in the CR spilling code.
This should eliminate the last place (outside of the prologue/epilogue) where
we depend on the unconditional availability of the r0 register. We will soon be
able to allocate it (in a somewhat restricted sense) as a GPR.
llvm-svn: 178060
PPC's use of PEI's virtual-register-based scavenging functionality had
redefined the virtual registers (it was non-SSA). Now that PEI supports
dealing with instructions with multiple virtual registers, this can be
cleanup up to use multiple virtual registers and keep SSA form.
No functionality change intended.
llvm-svn: 178059
The previous algorithm could not deal properly with scavenging multiple virtual
registers because it kept only one live virtual -> physical mapping (and
iterated through operands in order). Now we don't maintain a current mapping,
but rather use replaceRegWith to completely remove the virtual register as
soon as the mapping is established.
In order to allow the register scavenger to return a physical register killed
by an instruction for definition by that same instruction, we now call
RS->forward(I) prior to eliminating virtual registers defined in I. This
requires a minor update to forward to ignore virtual registers.
These new features will be tested in forthcoming commits.
llvm-svn: 178058
- Making an error message more consistent
- Ensuring the element size is not zero before using it in a modulus
- Properly using target settings to cap the std::list element count
- Removing spurious element size calculations that were unused
- Removing spurious capping in std::map
llvm-svn: 178057
Required making a handful of changes to the table generator. Also adds
an unspecified inheritance attribute. This opens the path for us to
apply these attributes to C++ records implicitly.
llvm-svn: 178054
Now all x86 instructions that have itinerary classes also have SchedRW
lists. This is required before the new scheduling models can be used.
There are still unannotated instructions remaining, but they don't have
itinerary classes either.
llvm-svn: 178051
- 'prefetch' intrinsics are only lowered when SSE is available. On non-X86
builds, 'generic' CPU is used and stops lowering any prefetch intrinsics.
llvm-svn: 178046
This is a compile time optimization. Before the patch we would do two traversals
on each call to aliasGEP - one with a set size parameter one with UnknownSize.
We can do better by first checking the result of the alias query with
UnknownSize.
Only if this one returns MayAlias do we query a second time using size and type.
This recovers an about 7% compile time regression on spec/ammp.
radar://12349960
llvm-svn: 178045
ValueObjects themselves use DumpValueObjectOptions as the currency for the same purpose
The code to convert between these two units was replicated (to varying degrees of correctness) in several spots in the code
This checkin provides one and only one (and hopefully correct :-) entry point for this conversion
llvm-svn: 178044
- Add head 'prfchwintrin.h' to define '_m_prefetchw' which is mapped to
LLVM/clang prefetch builtin
- Add option '-mprfchw' to enable PRFCHW feature and pre-define '__PRFCHW__'
macro
llvm-svn: 178041
For each macro directive (define, undefine, visibility) have a separate object that gets chained
to the macro directive history. This has several benefits:
-No need to mutate a MacroDirective when there is a undefine/visibility directive. Stuff like
PPMutationListener become unnecessary.
-No need to keep extra source locations for the undef/visibility locations for the define directive object
(which is the majority of the directives)
-Much easier to hide/unhide a section in the macro directive history.
-Easier to track the effects of the directives across different submodules.
llvm-svn: 178037
Summary:
The only vector types a user can pass from MSVC code to clang code are
the ones from *mmintrin.h, so we only have to match the MSVC mangling
for these types. MSVC mangles the __m128 family of types as tag types,
which we match. For other vector types, we emit a unique tag type
mangling that won't match anything produced by MSVC.
Reviewers: rjmccall
CC: chandlerc, timurrrr, cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D576
llvm-svn: 178036
Sam Panzer, author of loop convert, provided a list of limitations of the tool
to be documented. (Thanks Sam!)
The transform's limitations are now documented in the existing user doc.
Included are examples of the cases where the tool may change semantics.
Author: Jack Yang <jack.yang@intel.com>
llvm-svn: 178034
Michael Liao