Recognize if-like Tree.MultiSegmentApp as IfThenElse IR #11365
Conversation
JaroslavTulach
requested review from
4e6,
hubertp and
Akirathan
as code owners
|
To keep compatibility with original from Standard.Base import all
type X
Ok
Bad
if_then_else self ~t ~f = case self of
X.Ok -> t
X.Bad -> f
if_then self ~t = case self of
X.Ok -> t
X.Bad -> Nothing
main =
a = X.Ok.if_then_else "true" "false"
b = X.Bad.if_then_else "true" "false"
c = if X.Ok then "true" else "false"
d = if X.Bad then "true" else "false"
x = X.Ok.if_then "true"
y = X.Bad.if_then "true"
z = if X.Ok then "true"
w = if X.Bad then "true"
[a, b, c, d, x, y, z, w]should print It has to be Boolean!Decision: The condition of |
|
Instrumenter_Spec tests are failing probably because we don't support instrumentation inside of |
|
While working on this PR I realized that we represent every Creating wip/jtulach/LazyIfCaseOfBranches9165 branch and measuring startup again and engine. Let's see the result! |
|
After running engine benchmarks it looks like just converting
Quite contrary. The most essential benchmark is slowing down. I guess direct conversion of This state of work is now preserved as ConvertingIfThenElseToCaseExpr and this PR will try to go different direction. |
…e all the sub-branches
… FrameAnalysisMeta is different.
| @@ -3441,6 +3448,7 @@ lazy val `runtime-compiler-dump-igv` = | |||
| (project in file("engine/runtime-compiler-dump-igv")) | |||
| .enablePlugins(JPMSPlugin) | |||
| .settings( | |||
| customFrgaalJavaCompilerSettings("21", true), | |||
There was a problem hiding this comment.
- adjusting Dump compiler IR to IGV #12061
- Making sure sources of
runtime-compiler-dump-igvare visible toenso4igvtooling.
|
Looks like our sbt:enso> runEngineDistribution --run test/Base_Tests
2944 tests succeeded.
0 tests failed.
48 tests skipped.
17 groups skipped.running unit tests... That's not that bad - after months of not being able to make a progress, that's actually not that far from ideal. |
There was a problem hiding this comment.
Since #11770 is merged, try to implement IfThenElse like CallArgument and not as Scala case class.
There was a problem hiding this comment.
That's indeed desirable. Done in 40edc67 and it looks great, simple and easy to use. Except few gotchas in the generated code:
protected diagnostics, passData, locationare wrong - they shouldn't be protected, butprivateObjects.equals(this.passData, other.passData)is wrong (and I am surprised it even works) - it should bethis.passData == other.passDatashowCode(int)should be abstract to force implementors to implement it
Pull Request Description
Fixes #9165 by recognizing
if/then/elsein a special way. Introduces newIfThenElseIRelement to represent bothif_then_elseas well asif_thencases. Such element needs to be recognized by variousIRprocessing passes and at the end converted into executableIfThenElseNodeinIrToTruffle.Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:
Scala,
Java,