[SwiftCompilerSources] Moved Test into Optimizer.

[nate-chandler]

Based on #69007 .

In order to change the type of the context argument to FunctionPassContext. In the fullness of time could be sunk into the SIL module.

[nate-chandler]

@swift-ci please test

[atrick]

If we want the SIL module to be useful, rather than just adding unnecessary layering complexity, then we'll need to move Context along with a slew of other SIL utilities. But that's a separate task. For now, it doesn't really make sense to put much of anything in the SIL module.

FunctionPassContext is the only context that makes sense for FunctionTest and doesn't seem at all specific to running a pass. So it's right to assume that all SIL tests should get one. We could have a separate FunctionTestContext that duplicates everything in FunctionPassContext, but that just seems pointless.

[nate-chandler]

@swift-ci please smoke test and merge

[eeckstein]

@atrick, @nate-chandler

If we want the SIL module to be useful, rather than just adding unnecessary layering complexity, then we'll need to move Context along with a slew of other SIL utilities.

SIL is not a layer but the data definition for SIL. It's currently bridging to C++ but at some day (far in the future) SIL will be purely implemented in swift.
Nevertheless, I agree that it makes sense to move some basic Context types to SIL.

FunctionPassContext is the only context that makes sense for FunctionTest [...]

See my comment in the other PR.

With test context there is a more fundamental layering problem. The test context needs to provide things like the dominator tree, but analysis are implemented in the optimizer. This makes it impossible to implement tests for SIL utilities which depend on analysis like the dominator tree.

What I think we should do in the longer term is to split out tests into a separate module, which can depend on the optimizer module. Or even split the optimizer into multiple modules, where one of this contains all the analysis (Analysis).

[nate-chandler]

to split out tests into a separate module

An important aspect of these tests is that they're inline, next to the code being tested, able even to test code that isn't exported from a module.

The test context needs to provide things like the dominator tree, but analysis are implemented in the optimizer. This makes it impossible to implement tests for SIL utilities which depend on analysis like the dominator tree.

As long as the driver is able to produce a dominator tree and provide it to the test, it's fine for the dominator tree to depend on things that aren't visible in the module.

[eeckstein]

As discussed offline, we could move all the Analysis types from the Optimizer to the SIL module.

[atrick]

Note that it would be fine to have a more basic TestContext that does not depend on the Optimizer. But to get things working, we need a context that has all the capabilities of a function pass. I initially called that FunctionPassTestContext, but Nate didn't want separate FunctionTest and FunctionPassTest. I agree that we don't need both.

[atrick]

As discussed offline, we could move all the Analysis types from the Optimizer to the SIL module.

For anyone trying to understand the compiler architecture, there is a helpful distinction between logic that (1) defines valid SIL, (2) makes it possible to work with SIL, and (3) pure optimization. I would expect the first two to be part of the SIL module. Things like intrusive data types obviously need to be in SIL because they are tightly coupled. Most utilities and basic analyses need to be in SIL. AliasAnalysis is a good example of something that should have an interface in SIL but should ideally be mostly implemented in the optimizer. (Ideally valid SIL only depends on trivial disambiguation, not arbitrarily complex analysis). Today, we rely on full AliasAnalysis for valid SIL. That's an important (controversial) architectural decision which would be made clear by moving AliasAnalysis to SIL.

I don't know if there's any other reason to split things into modules. I think the "data model" is an implementation detail. We can encode information about a SIL type in a routine or cache the information in flags. They're both part of SIL.