Assertion failed: (NumUsePointsToFind > 0 && "There must be at least one
releasing instruction for an alloc"), function canPromoteAlloc
Revert "Fix comment for StackPromotion pass in SIL Passes"
Revert "Reapply the StackPromotion commit
0dd045ca04dcc10a33abf57f7e1b08260c4e3de1."
This reverts commit 3f4b1496bd and commit
199cfca13b.
It promotes allocations of native swift objects and array buffers to the stack if it is possible.
The SIL StackPromotion pass is the main part of the optimization. For details see comments there.
Unfortunately we need an additional LLVM pass to handle array buffers, which is not very nice.
I hope that we can get rid of it in future (again: for details see the comments in StackPromotion.cpp)
The optimization gives performance improvements in some benchmarks, mostly related to array literals:
ArrayLiteral: +12%
Combos: +16%
DictionaryLiteral: + 37%
RIPEMD: +10%
StringBuilder: +27%
StringInterpolation: +11%
And last but not least the new benchmark which is dedicated to test stack promotion:
ObjectAllocation: +52%
llvm-swift-opt is a swift only version of opt that will be used to remove
swift's dependency on dynamically injecting passes into opt and to allow for
IRGen's LLVM pipeline to be simulated exactly by reusing the IRGen pass pipeline
building code.
The reason to remove the dynamic code is that it seems that this is code that
will be in flux vis-a-vis the transition to the new pass manager in LLVM, so it
makes sense to make this change now due to the benefit provided by exactly
simulating IRGen.
Swift SVN r32804
The SLPVectorizer vectorizes loads from a packed struct of i2s.
{<i2, i2, i2, i2>}
The problem with that is that LLVM codegens scalar accesses to such a type as
if it where a packed i8 struct.
So when we emit a vector load of <4 x i2> (i.e one byte) and extract any non
zero index element we get garbage. Disable the SLPVectorizer until it is fixed.
rdar://22673382
Swift SVN r32299
The new implementation needs to happen after all source files have been built and before lazy definitions are emitted, but I neglected to insert it in the parallel IRGen path. Fixes rdar://problem/22825770.
Swift SVN r32189
inside a swift ast section in an object file so it can be passed to the
linker. The driver automatically wraps merged swiftmodules iff the target
is ELF.
rdar://problem/22407666
Swift SVN r31641
By using relative references, either directly to symbols internal to the current TU, or to the GOT entry for external symbols, we avoid unnecessary runtime relocations, and we save space on 64-bit platforms, since a single image is still <2GB in size. For the 64-bit standard library, this trades 26KB of fake-const data in __DATA,__swift1_proto for 13KB of true-const data in __TEXT,__swift2_proto. Implements rdar://problem/22334380.
Swift SVN r31555
This pass does things similar to LLVMARCContract so it makes sense to use the
same naming schema.
Also I am going to be implementing some contracting optimziations here later
today.
Swift SVN r30203
The test that it's guarding is cheap enough to do all the time, and we
don't have any interesting configurations where it's not set any more.
Swift SVN r29442
We need this because that global state includes tables like llvm[.compiler].used
which would otherwise be sorely missed.
This fixes an issue of the clang importer that would cause us to fail whenever
we imported a function (say it is marked as static inline) that performs an
objective-c method call and we optimize the code. The optimizer would not see
the objective-c selector global variable (which is marked private) as being
"used by unkown i.e the objc runtime" and would rightly assume it could
propagate the value of the global variable's initializer value as a constant to
loads of the global variable.
Now we call the ClangCodeGenerators translation unit finalization code which
will emit these tables and other module flags. We need to take care that we
merge those datastrutures with datastructures that we emit from swift's IRGen.
rdar://21115194
Swift SVN r29176
We already do for the iOS simulator and the tvOS simulator. This fixes
the 'unrecognized selector sent to instance’ bridging crashes in the stdlib
watch simulator tests.
Greg Parker did the hard work of tracking this down and suggested the fix.
<rdar://problem/20932146>
Swift SVN r28846
It is broken. clang does not enable it by default.
We might consider renabling it. But while we are triaging bugs it makes sense to
disable it.
rdar://20848016
Swift SVN r28483
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
It can be enabled with the -num-threads <n> option.
Without this option there should be NFC.
When enabled, the LLVM IR is split into multiple modules: one module for each input file.
And for each module an output file is generated. All output files must be specified with -o options:
for each input file in the command line there must be an -o <outputfile> option.
LLVM compilation is performed on each module separately.
This means that the generated code is different than with regular -wmo.
But performance and code size should be approximately the same because important inter-file
optimizations are already done at SIL level (e.g. inlining, specialization).
There is still no support in the driver for this feature.
Swift SVN r25930
This will be needed for split-llvm code generation.
If multiple -o options are specified and only a single output file is needed
(currently always), the last one wins. This is NFC.
Swift SVN r25884
Move helper function EmbedBitcode() from frontend_main.cpp to IRGen.cpp so we
can call it from performIRGeneration when the input file is Swift.
Add testing case to make sure that -embed-bitcode-marker option adds an
empty LLVM bitcode section.
rdar://19048891
Swift SVN r25577
