cmd/compile: inlining mark elimination is fragile #32069
Labels
compiler/runtime
Issues related to the Go compiler and/or runtime.
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
[broken out from #32068]
If you remove the following rule from generic.rules
(Geq(64|32|16|8) (Const(64|32|16|8) [c]) (Const(64|32|16|8) [d])) -> (ConstBool [b2i(c >= d)])
and recompile math/cmplx.Inf, you get similar generated code. The constant folding that did not occur during generic opt occurs in lowered opt. (The generated code isn't identical, but I'm working on that independently.)
However, if the constant folding occurs during lowered opt, there is no inlining nop at the beginning of the function.
Either we need one, or we don't; it shouldn't be sensitive to whether a particular generic constant folding optimization occurs.
cc @randall77 for inlining marks
The text was updated successfully, but these errors were encountered: