Tim Kientzle
f09fb7dfa4
Update a couple of files to pull assertion helpers from the new header
2024-05-16 12:50:23 -07:00
Ben Barham
ef8825bfe6
Migrate llvm::Optional to std::optional
...
LLVM has removed llvm::Optional, move over to std::optional. Also
clang-format to fix up all the renamed #includes.
2024-02-21 11:20:06 -08:00
Nate Chandler
9e13a38a6c
[Gardening] AddressLowering: Comment punctuation.
2023-10-30 07:49:11 -07:00
Nate Chandler
4d3c32d261
[AddressLowering] NFC: Added print.
...
Allow in-IR tests to print to stdout.
2023-10-20 18:16:38 -07:00
Nate Chandler
09511a726e
[AddressLowering] NFC: Marked dump const.
2023-10-19 09:00:52 -07:00
Manu
02b5fa2c8e
Fix some typos in the codebase
2023-08-31 18:50:10 -03:00
Nate Chandler
a27b3909d4
[AddressLowering] Sink projections to uses.
...
Visit the tree of projections in post-order, sinking each to the lowest
position in the least common ancestor of all uses.
2023-07-26 16:41:57 -07:00
Nate Chandler
604150c194
[AddressLowering] Place projections below types.
...
Projections may involve opened archetypes. They must be dominated by
the instructions which open those archetypes.
When determining the earliest storage point for a value and the point at
which to insert its projections, look for such obstructions in the
projection chain. The first one found is the earliest storage point.
2023-07-26 16:41:57 -07:00
Nate Chandler
c9d84295eb
[AddressLowering] Project at storage.
...
The pass rewrites opaque values in reverse post order of their
definitions. When an opaque value is rewritten, both its definition and
its uses are rewritten. When a def or a use is rewritten, in order to
materialize an address with which to rewrite, projection instructions
are created. Previously, these projections were created at the site of
the def or use. Some of these projection instructions may be reused when
rewriting later opaque values.
As a result, it's possible to have two opaque values `A` and `B` (which
are rewritten in that order) such that rewriting a use of `A` which
occurs "after" the def (or a use) of `B` creates a projection `P` which
is then used by that "earlier" def (or use) of `B`:
```
A =
B = // relies on P
use B
use A // creates some projection P
```
When rewriting the def (or that use, respectively) of `B`, the
projection which was created for the use of `A` will be reused. And
previously, the projection would be created at the use of A. But that
projection instruction was "after" the place where it is used when
rewriting the def or use of `B`. That's invalid!
To address this, rather than creating projections at the instruction
being rewritten, instead create them "as early as possible". The
locations where they will be created are chosen so as to dominate all
uses.
2023-07-26 16:41:57 -07:00
Nate Chandler
de8e1829c3
[AddressLowering] Prevent existential multi-init.
2023-07-25 08:41:07 -07:00
Nate Chandler
a4aef5463e
[AddressLowering] NFC: Add projection iterator.
...
Used the iterator to replace recursion in get*Storage functions with for
loops.
2023-07-25 08:40:47 -07:00
Nate Chandler
d9cf437ec3
[AddressLowering] NFC: Added const variant.
...
Of existing function getProjectedStorage.
2023-07-25 08:40:44 -07:00
Nate Chandler
e3428aeb95
[AddressLowering] NFC: Add more dump functions.
2023-07-25 08:40:39 -07:00
Nate Chandler
ba6b0192fe
[AddressLowering] NFC: Comment projection chains.
...
Describe what all chains look like by analyzing the four theoretically
possible kinds of links--only three of the four are actually possible.
2023-07-25 08:40:37 -07:00
Nate Chandler
5ce0148c2a
[Gardening] Tweaked comment.
2022-10-26 07:57:55 -07:00
Josh Soref
730b16c569
Spelling siloptimizer
...
* access
* accessed
* accesses
* accessor
* acquiring
* across
* activated
* additive
* address
* addresses'
* aggregated
* analysis
* and
* appropriately
* archetype
* argument
* associated
* availability
* barriers
* because
* been
* beginning
* belongs
* beneficial
* blocks
* borrow
* builtin
* cannot
* canonical
* canonicalize
* clazz
* cleanup
* coalesceable
* coalesced
* comparisons
* completely
* component
* computed
* concrete
* conjunction
* conservatively
* constituent
* construct
* consuming
* containing
* covered
* creates
* critical
* dataflow
* declaration
* defined
* defining
* definition
* deinitialization
* deliberately
* dependencies
* dependent
* deserialized
* destroy
* deterministic
* deterministically
* devirtualizes
* diagnostic
* diagnostics
* differentiation
* disable
* discipline
* dominate
* dominates
* don't
* element
* eliminate
* eliminating
* elimination
* embedded
* encounter
* epilogue
* epsilon
* escape
* escaping
* essential
* evaluating
* evaluation
* evaluator
* executing
* existential
* existentials
* explicit
* expression
* extended
* extension
* extract
* for
* from
* function
* generic
* guarantee
* guaranteed
* happened
* heuristic
* however
* identifiable
* immediately
* implementation
* improper
* include
* infinite
* initialize
* initialized
* initializer
* inside
* instruction
* interference
* interferes
* interleaved
* internal
* intersection
* intractable
* intrinsic
* invalidates
* irreducible
* irrelevant
* language
* lifetime
* literal
* looks
* materialize
* meaning
* mergeable
* might
* mimics
* modification
* modifies
* multiple
* mutating
* necessarily
* necessary
* needsmultiplecopies
* nonetheless
* nothing
* occurred
* occurs
* optimization
* optimizing
* original
* outside
* overflow
* overlapping
* overridden
* owned
* ownership
* parallel
* parameter
* paths
* patterns
* pipeline
* plottable
* possible
* potentially
* practically
* preamble
* precede
* preceding
* predecessor
* preferable
* preparation
* probably
* projection
* properties
* property
* protocol
* reabstraction
* reachable
* recognized
* recursive
* recursively
* redundant
* reentrancy
* referenced
* registry
* reinitialization
* reload
* represent
* requires
* response
* responsible
* retrieving
* returned
* returning
* returns
* rewriting
* rewritten
* sample
* scenarios
* scope
* should
* sideeffects
* similar
* simplify
* simplifycfg
* somewhat
* spaghetti
* specialization
* specializations
* specialized
* specially
* statistically
* substitute
* substitution
* succeeds
* successful
* successfully
* successor
* superfluous
* surprisingly
* suspension
* swift
* targeted
* that
* that our
* the
* therefore
* this
* those
* threshold
* through
* transform
* transformation
* truncated
* ultimate
* unchecked
* uninitialized
* unlikely
* unmanaged
* unoptimized key
* updataflow
* usefulness
* utilities
* villain
* whenever
* writes
Signed-off-by: Josh Soref <jsoref@users.noreply.github.com >
2022-10-03 18:31:33 -04:00
Meghana Gupta
60d0ac6b4e
[SIL Opaque Value] Support checked_cast_br in Address Lowering with loadable source type and opaque target type ( #58441 )
2022-05-05 11:55:00 -07:00
Andrew Trick
f4176b9111
[SIL-opaque] Code review suggestions
...
Mostly documentation and typos.
2022-03-09 17:18:15 -08:00
Andrew Trick
b187ba0dde
Add support for indirect tuple-type results.
...
This could happen as a result of specialization or concrete
address-only values.
For now, it's just tested by SIL unit tests.
2022-03-09 17:18:15 -08:00
Andrew Trick
b90007a98c
Update and reimplement AddressLowering pass (for SIL opaque values).
...
Merge the AddressLowering pass from its old development branch and update
it so we can begin incrementally enabling it under a flag.
This has been reimplemented for simplicity. There's no point in
looking at the old code.
2022-03-09 17:18:15 -08:00
