Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Warn for all LD that can be optimized to LDH, not only first #1114

Closed
pinobatch opened this issue Dec 11, 2022 · 1 comment
Closed

Warn for all LD that can be optimized to LDH, not only first #1114

pinobatch opened this issue Dec 11, 2022 · 1 comment

Comments

@pinobatch
Copy link
Member

By default, RGBASM optimizes ld to ldh where possible. I'm told the default will soon change to no optimization, in the interest of what you write is what you get. If the user specifies neither optimization nor no optimization on the command line, RGBASM emits a warning (from parser.y) when optimizing. However, RGBASM suppresses this warning (warnOnLdOpt = false;) after the first occurrence in each translation unit, making it more tedious for me to go in and fix them all.

So here's the behavior that I'd like to see going forward (names are flexible):

  1. -L, -fno-ldh, --preserve-ld (default): no optimization
  2. -l, -fldh, --auto-ldh: optimization
  3. -Wldh to trigger this warning without suppressing it after the first instance
@Rangi42
Copy link
Contributor

Rangi42 commented Dec 11, 2022

Issue #986 is regarding the gradual deprecation and removal of ld-to-ldh auto-optimization (and the similar nop-after-halt auto-insertion). Previously they were the default behavior, with -L and -h flags to disable that behavior. Currently the -l and -H flags exist to explicitly enable them, and the first usage of ld or halt triggers a warning if you didn't explicitly opt into or opt out of the behavior. In the next release the no-behavior will be the default, with opting into the auto-behavior warned as deprecated, then removed in the release after that.

Separately, issue #1017 is regarding RGBLINK warnings for possible optimizations (but not doing them automatically). Those could be allowed for all instances or only the first, and could exist for many such patterns (ld when it could be ldh, but also jp when it could be jr, and maybe others like tail call+ret, redundant operations, etc). This would have to be a link-time behavior since too much might be unknown at asm time.

I think this issue can be closed as a duplicate of those.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants