Merged
Conversation
Signed-off-by: Andrew Young <youngar17@gmail.com>
This also fixes compiler issues related to constructor signature changes Signed-off-by: Andrew Young <youngar17@gmail.com>
This causes a compiler error on Linux but not OSX Signed-off-by: Andrew Young <youngar17@gmail.com>
The DoWhile and WhileDo services are renabled, but they do not support being recorded. If there is an active recorder we will assert that these services do not support recording. With this change we can compile and run the test compiler, and it will assert if we attempt to run with a recorder. Signed-off-by: Andrew Young <youngar17@gmail.com>
youngar
force-pushed
the
jitbuilder_replay
branch
from
5d49d3b to
74093bd
Compare
Owner
|
Sorry I took so long to get to this Andrew. I think the changes are reasonable for this branch in its current state. Thanks! |
Author
|
Hi Mark, thank you for merging! I don't think you could say I "fixed" anything, but at least now we can build the compiler test. Since the EB team is done the first dragons den, I believe they will be coding a lot more! I'm pretty excited to see what they roll out. |
mstoodle
pushed a commit
that referenced
this pull request
Jul 30, 2021
Tests fail in the following way: ``` 18:26:45 [----------] 450 tests from SelectCompareTest/Int32SelectInt8CompareTest 18:26:45 Assertion failed at /home/jenkins/workspace/Build/compiler/riscv/codegen/OMRTreeEvaluator.cpp:114: false 18:26:45 Opcode bcmpeq is not implemented 18:26:45 18:26:45 compiling file:line:name at level: warm 18:26:45 #0: function TR_LinuxCallStackIterator::printStackBacktrace(TR::Compilation*)+0x2a [0x40017112f4] 18:26:45 #1: function TR_Debug::printStackBacktrace()+0x28 [0x40014f2f42] 18:26:45 #2: ./fvtest/compilertriltest/comptest(+0x133a28e) [0x400133a28e] 18:26:45 eclipse-omr#3: ./fvtest/compilertriltest/comptest(+0x133a366) [0x400133a366] 18:26:45 eclipse-omr#4: function TR::assertion(char const*, int, char const*, char const*, ...)+0xac [0x400133a416] 18:26:45 eclipse-omr#5: function OMR::RV::TreeEvaluator::unImpOpEvaluator(TR::Node*, TR::CodeGenerator*)+0x56 [0x4001523796] 18:26:45 eclipse-omr#6: function OMR::CodeGenerator::evaluate(TR::Node*)+0x1a2 [0x4001540254] 18:26:45 eclipse-omr#7: function OMR::RV::TreeEvaluator::iselectEvaluator(TR::Node*, TR::CodeGenerator*)+0x6e [0x4001723a96] 18:26:45 eclipse-omr#8: function OMR::CodeGenerator::evaluate(TR::Node*)+0x1a2 [0x4001540254] 18:26:45 eclipse-omr#9: function genericReturnEvaluator(TR::Node*, OMR::RealRegister::RegNum, TR_RegisterKinds, TR_ReturnInfo, TR::CodeGenerator*)+0x4e [0x4001722790] 18:26:45 eclipse-omr#10: function OMR::RV::TreeEvaluator::ireturnEvaluator(TR::Node*, TR::CodeGenerator*)+0x42 [0x40017228c6] 18:26:45 eclipse-omr#11: function OMR::CodeGenerator::evaluate(TR::Node*)+0x1a2 [0x4001540254] ``` Signed-off-by: Filip Jeremic <fjeremic@ca.ibm.com>
mstoodle
added a commit
that referenced
this pull request
Feb 27, 2026
We have two competing goals for the contents of the optimizer
component: 1) we want to test everything, and 2) it would be
nice not to have to include everything if not everything is
needed. The Optimizer class currently pulls a bit of a swizzle
by using a macro to rip out all the default optimization and
group initializations so that a compiler extension can define
its own optimizer. Unfortunately, this puts all the onus onto
the compiler extension to know what it wants if it doesn't want
everything. That's what the jitbuilder compiler extension does.
Rather than this all or "tell me everything you want" approach,
we could create a couple of options available for downstream
compilers. I'm going to call them FullOptimizer (i.e. enable
everything) and SmallOptimizer (which coresponds to what jitbuilder
currently uses). In fact, FullOptimizer and SmallOptimzier are
extensible classes. By default, Optimizer.hpp will make
TR::Optimizer derive from TR::FullOptimizer. But a compiler
extension (like jitbuilder) can now get the simpler SmallOptimizer
in one of two ways:
1) provide an optimizer/Optimizer.hpp file that declares
TR::Optimizer extended from TR::SmallOptimizer.
2) define a macro OMR_OPTIMIZER_SMALL in the build and
exclude optimizer/FullOptimizer.cpp from the build files
By default, a compiler extension will get everything (which is
what was happening previously and some downstream projects like
OpenJ9 depend upon this behaviour). The original macro has been
removed which may introduce some downstream effects (though I'm
not explicitly aware of any projects using it)..
The jitbuilder project will now follow option #2 above (defining
the macro and excluding the file). The test compiler in
fvtest/compilertest will be built with FullOptimizer so both
approaches can and will be tested within the OMR project.
As part of this change, I also cleaned up the creation of
the Optimizer object as well as some of the handling of
the optimizationStrategy selection. OpenJ9, because it
more substantially extended the OMR optimizer, requires
some downstream changes in this area but it may be the only
downstream consumer that will encounter issues.
This change completely eliminates two of the more complex files
required in compiler extensions and simplifies how compiler
extensions (downstream projects) can choose the desired optimizer
configuration.
Signed-off-by: Mark Stoodley <mstoodle@ca.ibm.com>
more optimizer fixes
Signed-off-by: Mark Stoodley <mstoodle@ca.ibm.com>
mstoodle
added a commit
that referenced
this pull request
Feb 27, 2026
We have two competing goals for the contents of the optimizer
component: 1) we want to test everything, and 2) it would be
nice not to have to include everything if not everything is
needed. The Optimizer class currently pulls a bit of a swizzle
by using a macro to rip out all the default optimization and
group initializations so that a compiler extension can define
its own optimizer. Unfortunately, this puts all the onus onto
the compiler extension to know what it wants if it doesn't want
everything. That's what the jitbuilder compiler extension does.
Rather than this all or "tell me everything you want" approach,
we could create a couple of options available for downstream
compilers. I'm going to call them FullOptimizer (i.e. enable
everything) and SmallOptimizer (which coresponds to what jitbuilder
currently uses). In fact, FullOptimizer and SmallOptimzier are
extensible classes. By default, Optimizer.hpp will make
TR::Optimizer derive from TR::FullOptimizer. But a compiler
extension (like jitbuilder) can now get the simpler SmallOptimizer
in one of two ways:
1) provide an optimizer/Optimizer.hpp file that declares
TR::Optimizer extended from TR::SmallOptimizer.
2) define a macro OMR_OPTIMIZER_SMALL in the build and
exclude optimizer/FullOptimizer.cpp from the build files
By default, a compiler extension will get everything (which is
what was happening previously and some downstream projects like
OpenJ9 depend upon this behaviour). The original macro has been
removed which may introduce some downstream effects (though I'm
not explicitly aware of any projects using it)..
The jitbuilder project will now follow option #2 above (defining
the macro and excluding the file). The test compiler in
fvtest/compilertest will be built with FullOptimizer so both
approaches can and will be tested within the OMR project.
As part of this change, I also cleaned up the creation of
the Optimizer object as well as some of the handling of
the optimizationStrategy selection. OpenJ9, because it
more substantially extended the OMR optimizer, requires
some downstream changes in this area but it may be the only
downstream consumer that will encounter issues.
This change completely eliminates two of the more complex files
required in compiler extensions and simplifies how compiler
extensions (downstream projects) can choose the desired optimizer
configuration.
Signed-off-by: Mark Stoodley <mstoodle@ca.ibm.com>
more optimizer fixes
Signed-off-by: Mark Stoodley <mstoodle@ca.ibm.com>
mstoodle
added a commit
that referenced
this pull request
Feb 27, 2026
We have two competing goals for the contents of the optimizer
component: 1) we want to test everything, and 2) it would be
nice not to have to include everything if not everything is
needed. The Optimizer class currently pulls a bit of a swizzle
by using a macro to rip out all the default optimization and
group initializations so that a compiler extension can define
its own optimizer. Unfortunately, this puts all the onus onto
the compiler extension to know what it wants if it doesn't want
everything. That's what the jitbuilder compiler extension does.
Rather than this all or "tell me everything you want" approach,
we could create a couple of options available for downstream
compilers. I'm going to call them FullOptimizer (i.e. enable
everything) and SmallOptimizer (which coresponds to what jitbuilder
currently uses). In fact, FullOptimizer and SmallOptimzier are
extensible classes. By default, Optimizer.hpp will make
TR::Optimizer derive from TR::FullOptimizer. But a compiler
extension (like jitbuilder) can now get the simpler SmallOptimizer
in one of two ways:
1) provide an optimizer/Optimizer.hpp file that declares
TR::Optimizer extended from TR::SmallOptimizer.
2) define a macro OMR_OPTIMIZER_SMALL in the build and
exclude optimizer/FullOptimizer.cpp from the build files
By default, a compiler extension will get everything (which is
what was happening previously and some downstream projects like
OpenJ9 depend upon this behaviour). The original macro has been
removed which may introduce some downstream effects (though I'm
not explicitly aware of any projects using it)..
The jitbuilder project will now follow option #2 above (defining
the macro and excluding the file). The test compiler in
fvtest/compilertest will be built with FullOptimizer so both
approaches can and will be tested within the OMR project.
As part of this change, I also cleaned up the creation of
the Optimizer object as well as some of the handling of
the optimizationStrategy selection. OpenJ9, because it
more substantially extended the OMR optimizer, requires
some downstream changes in this area but it may be the only
downstream consumer that will encounter issues.
This change completely eliminates two of the more complex files
required in compiler extensions and simplifies how compiler
extensions (downstream projects) can choose the desired optimizer
configuration.
Signed-off-by: Mark Stoodley <mstoodle@ca.ibm.com>
more optimizer fixes
Signed-off-by: Mark Stoodley <mstoodle@ca.ibm.com>
mstoodle
added a commit
that referenced
this pull request
Mar 3, 2026
We have two competing goals for the contents of the optimizer
component: 1) we want to test everything, and 2) it would be
nice not to have to include everything if not everything is
needed. The Optimizer class currently pulls a bit of a swizzle
by using a macro to rip out all the default optimization and
group initializations so that a compiler extension can define
its own optimizer. Unfortunately, this puts all the onus onto
the compiler extension to know what it wants if it doesn't want
everything. That's what the jitbuilder compiler extension does.
Rather than this all or "tell me everything you want" approach,
we could create a couple of options available for downstream
compilers. I'm going to call them FullOptimizer (i.e. enable
everything) and SmallOptimizer (which coresponds to what jitbuilder
currently uses). In fact, FullOptimizer and SmallOptimzier are
extensible classes. By default, Optimizer.hpp will make
TR::Optimizer derive from TR::FullOptimizer. But a compiler
extension (like jitbuilder) can now get the simpler SmallOptimizer
in one of two ways:
1) provide an optimizer/Optimizer.hpp file that declares
TR::Optimizer extended from TR::SmallOptimizer.
2) define a macro OMR_OPTIMIZER_SMALL in the build and
exclude optimizer/FullOptimizer.cpp from the build files
By default, a compiler extension will get everything (which is
what was happening previously and some downstream projects like
OpenJ9 depend upon this behaviour). The original macro has been
removed which may introduce some downstream effects (though I'm
not explicitly aware of any projects using it)..
The jitbuilder project will now follow option #2 above (defining
the macro and excluding the file). The test compiler in
fvtest/compilertest will be built with FullOptimizer so both
approaches can and will be tested within the OMR project.
As part of this change, I also cleaned up the creation of
the Optimizer object as well as some of the handling of
the optimizationStrategy selection. OpenJ9, because it
more substantially extended the OMR optimizer, requires
some downstream changes in this area but it may be the only
downstream consumer that will encounter issues.
This change completely eliminates two of the more complex files
required in compiler extensions and simplifies how compiler
extensions (downstream projects) can choose the desired optimizer
configuration.
Signed-off-by: Mark Stoodley <mstoodle@ca.ibm.com>
more optimizer fixes
Signed-off-by: Mark Stoodley <mstoodle@ca.ibm.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
If you can, please try to avoid creating a merge commit