For AArch64, the fix is duplicating the arm64 lines, since those are not
taken when testing Android/Linux which use AArch64 as the architecture.
For ARMv7, the change is supporting both trap and .inst 0xe7ffdefe.
According to llvm/lib/Target/ARM/ARMAsmPrinter.cpp, non-Darwin binutils
do not support the mnemonic trap, so an .inst is emitted instead. The
same instruction has to be used in both places, though.
For both architectures add the Android version of APP/NO_APP, which uses
@-symbols or // instead of ##.
Introduce and use the new `%target-abi` and `%target-import-type`
subsitutions in the IRGen tests. The former allows us to differentiate
between the Windows and SysV ABI differences and the latter for the
indirected import semantics required by PE/COFF. This makes all the
IRGen tests succeed on Windows.
These inline asm instructions are used to block branch folding when
optimizing, to ensure that we have unique trap locations (and associated
debug info) for each cond_fail.
We only need these when we're optimizing, and emitting them can block
fast isel, so only emit them when optimizing.
In 2e3c0b6, code was added to emit unique trap blocks for each
cond_fail, in order to make post-mortem debugging simpler (e.g. stack
traces have correct line/column information for the trapping location,
and it's easy to trace back to the specific jump that reaches the trap).
We didn't, however, do anything to ensure that LLVM wouldn't merge these
back together again. This is an attempt to do exactly that, after seeing
BranchFolding in the code generator merging traps into a single block.
The idea here is to emit empty inline asm strings marked as
side-effecting, and taking a unique integer argument. These come before
the trap call, so they should block any valid attempt at merging the
blocks back together.
Ideally trap would take an argument which uniquely identifies it, but
that isn't possible today.
This solution is potentially brittle in that in theory LLVM could still
merge the trap/unreachable and then branch to those after the unique asm
calls. We cannot fix that by putting another asm call after the trap,
because LLVM's CFG simplification will delete code after a trap.
rdar://problem/25216969
Till now, a SIL module would be only verified if an optimization has changed it. But if there were no changes, then no verification would happen and some SIL module format errors would stay unnoticed. This was happening in certain cases when reading a textual SIL module representation, which turned out to be broken, but SIL verifier wouldn't catch it.
Swift SVN r31863
To invoke the front-end on a SIL with whole-module optimizations enabled, execute:
swiftc -frontend myfile.sil
To invoke the front-end on a SIL without whole-module optimizations enabled, add a -primary-file option:
swiftc -frontend -primary-file myfile.sil
To invoke a sil-opt with whole-module optimizations enabled, use the -wmo option:
sil-opt myfile.sil -wmo
This change was need to be able to write SIL unit tests which should be compiled in the WMO mode.
Swift SVN r31862
All llvm::Functions created during IRGen will have target-cpu and target-features
attributes if they are non-null.
Update testing cases to expect the attribute in function definition.
Add testing case function-target-features.swift to verify target-cpu and
target-features.
rdar://20772331
Swift SVN r28186
Reapply commit r24722.
The original commit did not break the build. There appears to be an issue in
CoreAutomation (an iOS test failed with empty output). Follow up builds with
the original commit in succeeded.
Also apply Dimitri's patch to make the test condfail.sil portable.
Original message:
This significantly improves debugging experience as failures such as overflow
can be mapped back to a source line.
Code size impacts I measured on PerfTestSuite and libswift*.dylib was
neglectable.
__text section size increase:
0.24% bin/PerfTest_O
0.01% bin/PerfTest_Onone
0.20% libswift*.dylib
rdar://19118593
Swift SVN r24725
This significantly improves debugging experience as failures such as overflow
can be mapped back to a source line.
Code size impacts I measured on PerfTestSuite and libswift*.dylib was
neglectable.
__text section size increase:
0.24% bin/PerfTest_O
0.01% bin/PerfTest_Onone
0.20% libswift*.dylib
rdar://19118593
Swift SVN r24722