Commit Graph

19 Commits

Author SHA1 Message Date
Kit Barton
fbfd58ab92 Add the i128 builtin type to LLVM.
The i128 type is needed as a builtin type in order to support the v1i128 vector
type. The PowerPC ABI requires that the i128 and v1i128 types are handled
differently when passed as parameters to functions (i128 is passed in pairs of
GPRs, v1i128 is passed in a single vector register). 

http://reviews.llvm.org/D8564


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235196 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-17 15:32:15 +00:00
Chandler Carruth
ffc97a6ae1 [slp] Fix a nasty bug in the SLP vectorizer that Joerg pointed out.
Apparently some code finally started to tickle this after my
canonicalization changes to instcombine.

The bug stems from trying to form a vector type out of scalars that
aren't compatible at all. In this example, from x86_mmx values. The code
in the vectorizer that checks for reasonable types whas checking for
aggregates or vectors, but there are lots of other types that should
just never reach the vectorizer.

Debugging this was made more confusing by the lie in an assert in
VectorType::get() -- it isn't that the types are *primitive*. The types
must be integer, pointer, or floating point types. No other types are
allowed.

I've improved the assert and added a helper to the vectorizer to handle
the element type validity checks. It now re-uses the VectorType static
function and then further excludes weird target-specific types that we
probably shouldn't be touching here (x86_fp80 and ppc_fp128). Neither of
these are really reachable anyways (neither 80-bit nor 128-bit things
will get vectorized) but it seems better to just eagerly exclude such
nonesense.

I've added a test case, but while it definitely covers two of the paths
through this code there may be more paths that would benefit from test
coverage. I'm not familiar enough with the SLP vectorizer to synthesize
test cases for all of these, but was able to update the code itself by
inspection.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228899 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-12 02:30:56 +00:00
Benjamin Kramer
2991725fe2 Turn some DenseMaps that are only used for set operations into DenseSets.
DenseSet has better memory efficiency now.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223589 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-06 19:22:54 +00:00
David Blaikie
5401ba7099 Update SetVector to rely on the underlying set's insert to return a pair<iterator, bool>
This is to be consistent with StringSet and ultimately with the standard
library's associative container insert function.

This lead to updating SmallSet::insert to return pair<iterator, bool>,
and then to update SmallPtrSet::insert to return pair<iterator, bool>,
and then to update all the existing users of those functions...

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222334 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-19 07:49:26 +00:00
David Blaikie
1d4f28c6bc Remove StringMap::GetOrCreateValue in favor of StringMap::insert
Having two ways to do this doesn't seem terribly helpful and
consistently using the insert version (which we already has) seems like
it'll make the code easier to understand to anyone working with standard
data structures. (I also updated many references to the Entry's
key and value to use first() and second instead of getKey{Data,Length,}
and get/setValue - for similar consistency)

Also removes the GetOrCreateValue functions so there's less surface area
to StringMap to fix/improve/change/accommodate move semantics, etc.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222319 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-19 05:49:42 +00:00
Matt Arsenault
30392bf191 Consider addrspaces in canLosslesslyBitCastTo()
Make this conservatively correct and report false for different
address spaces, which might require a nontrivial translation.

Based on the few uses of this, I don't think this currently
breaks anything.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216846 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-31 19:19:57 +00:00
Craig Topper
431bdfc4c1 Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid needing to mention the size.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216158 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-21 05:55:13 +00:00
Craig Topper
db77b82ed5 Revert "Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid needing to mention the size."
Getting a weird buildbot failure that I need to investigate.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215870 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-18 00:24:38 +00:00
Craig Topper
f06c7072c2 Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid needing to mention the size.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215868 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-17 23:47:00 +00:00
Rafael Espindola
24623bab81 pr20588: add missing calls to va_end.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215212 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-08 15:57:37 +00:00
Craig Topper
0b6cb7104b [C++11] More 'nullptr' conversion. In some cases just using a boolean check instead of comparing to nullptr.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206252 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-15 06:32:26 +00:00
Craig Topper
ec0f0bc6af [C++11] More 'nullptr' conversion or in some cases just using a boolean check instead of comparing to nullptr.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205831 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-09 06:08:46 +00:00
Craig Topper
89aeb02b71 Mark some Type and EVT methods as LLVM_READONLY.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198115 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-28 16:17:26 +00:00
Kaelyn Uhrain
b95d0907fc Fix the segfault reported in PR 11990.
The sefault occurs due to an infinite loop when the verifier tries to
determine the size of a type of the form "%rt = type { %rt }" while
checking an alloca of the type.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196626 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-07 00:13:34 +00:00
Rafael Espindola
3221b5bd23 micro optimization: isSizedDerivedType is only called with arrays, vectors and structs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196604 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-06 20:12:19 +00:00
Benjamin Kramer
877ca3418f Simplify code. No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194383 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-11 14:54:34 +00:00
Dmitri Gribenko
5c332dbd30 Add ArrayRef constructor from None, and do the cleanups that this constructor enables
Patch by Robert Wilhelm.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181138 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-05 00:40:33 +00:00
Chandler Carruth
0b8c9a80f2 Move all of the header files which are involved in modelling the LLVM IR
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.

There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.

The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.

I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).

I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-02 11:36:10 +00:00
Chandler Carruth
c2c50cdcdc Rename VMCore directory to IR.
Aside from moving the actual files, this patch only updates the build
system and the source file comments under lib/... that are relevant.

I'll be updating other docs and other files in smaller subsequnet
commits.

While I've tried to test this, but it is entirely possible that there
will still be some build system fallout.

Also, note that I've not changed the library name itself: libLLVMCore.a
is still the library name. I'd be interested in others' opinions about
whether we should rename this as well (I think we should, just not sure
what it might break)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171359 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-02 09:10:48 +00:00