You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For your first point, it has always been the case that when flagalloc needs to "spill" and "restore" flags, it leaves the old flag computation behind. It shouldn't be too hard to eliminate those comparisons. It wouldn't even require a full deadcode pass, because we know the args of the comparison are still used.
For your second point, this is working as expected, sort of. CMPQmem are generated, but they need to be undone during flagalloc. The problem is that we first schedule the CMPQmem, then a CMPQ for the bounds check. Because the bounds check clobbers flags, flagalloc must move the flag computation later, but it doesn't think it is safe to move the load later (it is safe, in this case, but it isn't in general).
I don't know whether we should fix this by making the scheduling smarter (moving the bounds checks earlier, maybe?) or teaching flagalloc to know when it is ok to move the load later.
randall77
added
NeedsFix
The path to resolution is known, but the work has not been done.
and removed
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
labels
Mar 28, 2018
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?the newest master branch on March 25, 2018
Does this issue reproduce with the latest release?
not tried
What operating system and processor architecture are you using (
go env
)?amd64/ubuntu16.04
What did you do?
test commit 4b00d3f#diff-6b1f55ed5d66ec08fb9cbe82259791e9
is compiled to
which is expected. but
is compiled to
The issue here
The text was updated successfully, but these errors were encountered: