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
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
initializeBufferWithTakeOfBuffer value witness.
Attempt to use initializeBufferWithTakeOfBuffer in
some appropriate places.
There are some changes enabled by this which are
coming in a follow-up patch.
Swift SVN r20741
unexpected forematter from the superclass.
This requires a pretty substantial shift in the
generic-metadata allocation/initialization dance
because (1) we can't allocate class metadata without
knowing what the superclass is and (2) the offset
from the metadata cache entry to the address point is
no longer determined solely by the metadata pattern.
While I'm making invasive changes to metadata, fix
two race conditions in metadata creation. The first
is that we need to ensure that only one thread succeeds
at lazily creating a generic-metadata cache. The second
is that we need to ensure that only one thread actually
attempts to create a particular metadata; any others
should block until the metadata is successfully built.
This commit finishes rdar://17776354. LLDB will
need to adjust to the runtime-private metadata layout
changes.
Swift SVN r20537
Add value witnesses for destroyArray, initializeArrayWithCopy, and initializeArrayWithTake{FrontToBack,BackToFront}, and fill out the runtime value witness table implementations. Stub out the IRGen ones for now.
Swift SVN r16772
We won't have any types where copying has an effect on the bit pattern (except for blocks, which need special handling anyway), and copy_value having a result makes optimizations more complex, so remove it.
Swift SVN r15640
As part of the nominal type descriptor for a struct or class, build a function that lazily generates the vector of type metadata for the fields of the nominal type given an instantiation of the type's metadata. To cache this for nongeneric types, produce a global variable we can stash the result in, or for generic types, reserve some space in the metadata template so that generic metadata instantiation naturally provides a space for every instance of the type.
Reapplying now that the missing Float80 builtin metadata is available.
Swift SVN r15260
As part of the nominal type descriptor for a struct or class, build a function that lazily generates the vector of type metadata for the fields of the nominal type given an instantiation of the type's metadata. To cache this for nongeneric types, produce a global variable we can stash the result in, or for generic types, reserve some space in the metadata template so that generic metadata instantiation naturally provides a space for every instance of the type.
Swift SVN r15256
-emit-llvm in Clang is a modifier on the -S and -c actions. In Swift,
it's a separate action equivalent to "-S -emit-llvm". Be less ambiguous.
Part of the migration to the new driver.
Swift SVN r13029
Only claim spare bits we actually use as tag bits in the result of getTagBitsForPayloadCases(), and fix up some crashers in corner cases. Add some assertions so these APIs get tested as part of normal compiler runs, and some DEBUG() macros so interested compiler users can see what enum layout is doing with -debug-only=enum-layout. This should also lead to slightly better codegen for some multi-payload enums because we don't pointlessly try to gather spare bits from the entire payload anymore, only the bits we actually need to discern the tag.
Swift SVN r12314
When doing struct layout for fixed-layout structs or tuples, combine the spare bit masks of their elements to form the spare bit mask of the aggregate, treating padding between elements as spare bits as well.
For now, disable using these spare bits to form extra inhabitants for structs and tuples; we would need additional runtime work to expose these extra inhabitants for correct generic runtime behavior. This puts us in a weird situation where 'enum { case A(Struct), B, C }' spills a bit but 'enum { case A(Struct), B(Struct), C }' doesn't, but the work to make the former happen isn't immediately critical for String optimization.
Swift SVN r12165
If there's no script-mode file in a module, don't produce a top_level_code SILFunction for it, and don't consider emitting an LLVM global_ctor for it. We should never emit static constructors from user code anymore.
Swift SVN r11644
Start using null-page values as extra inhabitants when laying out single-payload enums that contain class pointers as their payload type. Don't use inhabitants that set the lowest bit, to avoid trampling potential ObjC tagged pointer representations. This means that 'T?' for class type T now has a null pointer representation. Enums with multiple empty cases, as well as nested enums like 'T??', should now have optimal representations for class type T as well.
Note that we don't yet expose extra inhabitants for aggregates that contain heap object references, such as structs with class fields, Swift function types, or class-bounded existentials (even when the existential has no witness tables).
Swift SVN r10061
Build a nominal type descriptor when we emit the metadata or generic metadata pattern for a nominal type, and put a reference into the formerly null slot in the struct or enum metadata. We need to make a place for them in class metadata; that'll come next.
Swift SVN r9492
- Change type attribute printing logic (in astprinter and the demangler)
to print in the new syntax
- Change the swift parser to only accept type attributes in the new syntax.
- Update canParseTypeTupleBody to lookahead over new-syntax type attributes.
- Update the testsuite to use the new syntax.
Swift SVN r9273
John noted that LLVM's ABI rules for Integers of Unusual Size cause them to be aligned like the largest native integer type even inside packed structs, making them unsuited for byte-accurate layout in cases where the payload is a non-power-of-two size, so we have to bite the bullet and lay them out as arrays of i8, bitcasting to the payload type to load and store the payload and tag parts.
This still colors outside of the lines a bit because loading or storing e.g. an i72 is going to touch an i128's worth of memory. Baby steps. It'd be nice to be able to load and reconsistute the i72 without having to load and mask together all of the individual bytes.
Swift SVN r9058
If the enum gets laid out with a non-power-of-two payload and an extra tag, such as { i72, i2 }, then LLVM's natural location for the extra tag is going to be different from where we actually want it, so let's do our own byte offset calculation by bitcasting to i8* and gepping instead of trying to gep the struct directly.
Swift SVN r9023
