This builtin returns true for types that might be ObjC class types. We want to use this builtin to optimize away NSArray handling for non-object Array types, so it needs to persist in SIL long enough for specialization to do its thing, but we never actually want to pay a runtime cost for this check, so always lower it to a constant value at IRGen time. Handle this by having canBeObjCClass return a tri-state "yes/maybe/no" result. In SILGen, we only fold away obviously "yes" or "no" cases, and in IRGen, we fold away "maybe" cases as "yes".
The optimizer will need to learn about this builtin too, but that part isn't done yet.
Swift SVN r13980
(This only fails under -DSWIFT_OPTIMIZED=NO; most likely due to an llvm bug.)
We've decided that it's best to specialize each arithmetic builtin that could overflow, instead of calling a separate generic "staticReport" builtin and passing it enough info to produce the message. The main advantage of this approach is that it would be possible for the compiler to customize the message and better link it to the builtin that overflows. For example, the constants that participated in the computation could be printed. In addition, less code will be generated and the compiler could, in the future, automatically emit the overflow diagnostics/trap at runtime.
This patch introduces new versions of op_with_overflow swift builtins. Which are lowered to llvm.op_with_overflow builtins in IRGen after the static diagnostics. If the last argument to the builtins evaluates to true, the overflow is unintentional. CCP uses the builtins to diagnose the overflow detectable at compile time. FixedPoint is changed to rely on these in implementation of primitive arithmetic operations.
Swift SVN r9328
This was causing massive failures at run-time.
This reverts commit 80081db973ccb7100741fea19ce8e8c116fc410f.
Conflicts:
lib/SILPasses/ConstantPropagation.cpp
test/SILPasses/constant_propagation.swift
test/SILPasses/constant_propagation2.sil
Swift SVN r9050
After talking to John, Joe, and Dave Z, we've decided that it's best to
specialize each arithmetic builtin that could overflow, instead of calling
a separate generic "staticReport" builtin and passing it enough info to
produce the message. The main advantage of this approach is that it
would be possible for the compiler to customize the message and better
link it to the builtin that overflows. For example, the constants that
participated in the computation could be printed. In addition, less code
will be generated and the compiler could, in the future, automatically
emit the overflow diagnostics/trap at runtime.
This patch introduces new versions of op_with_overflow swift builtins.
Which are lowered to llvm.op_with_overflow builtins in IRGen after the
static diagnostics. If the last argument to the builtins evaluates to true,
the overflow is unintentional. CCP uses the builtins to diagnose the overflow
detectable at compile time. FixedPoint is changed to rely on these in
implementation of primitive arithmetic operations.
Swift SVN r9034
And use them to decide if an llvm intrinsic apply instruction can be considered dead.
(This is a hack because it uses LLVM Global context. However, we already use
this approach elsewhere.)
Swift SVN r7404
Make the functions support a wider range of builtins and store types to make
it possible.
This is an optimization - the cached ID will be used for builtin identification,
instead of retrieval of the string name and using it as the key.
Swift SVN r7390
This adds builtin types Builtin.VecNxT, where N is a natural number
and T is a builtin type, which map down to the LLVM type <N x T>.
Update varous builtins to support vector arguments, e.g., binary
operations, comparisons, negation. Add InsertElement and
ExtractElement builtins for vectors.
On top of these builtins, add Vec4f and Vec4b structs to the standard
library, which provide 4xFloat and 4xBool vectors, respectively, with
basic support for arithmetic. These are mostly straw men, to be burned
down at our leisure.
Some issues as yet unresolved:
- Comparisons of Vec4f'ss are producing bogus Vec4b's, which I
haven't tracked down yet.
- We still don't support the shuffle builtin, although it should be
easy
- More testing!
Swift SVN r5820
allows access to any LLVM IR intrinsic that has types that can be mapped
to swift types. Notably, this excludes vector stuff, but there is a lot
of other goodness that can now be poked at.
Swift SVN r1890
