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

cmd/internal/obj/arm: .S is silently ignored in MOVW.S #20509

Closed
benshi001 opened this issue May 27, 2017 · 17 comments
Closed

cmd/internal/obj/arm: .S is silently ignored in MOVW.S #20509

benshi001 opened this issue May 27, 2017 · 17 comments
Milestone

Comments

@benshi001
Copy link
Member

For "MOVW $0xaaaaaaaa, R1", the constant pool is used and actually it is assembled to "LDR Reg <- off(PC)". And in this case a .S suffix is not supported.

But the current assembler silently generated the right binary code without giving any error message.

@gopherbot
Copy link

CL https://golang.org/cl/44335 mentions this issue.

@cherrymui
Copy link
Member

What does MOVW.S even mean? I don't think any form of MOVW should take a .S bit.

@benshi001
Copy link
Member Author

There is a mov instruction "MOV R1, R2" can take .S suffix.

@benshi001
Copy link
Member Author

Now CL 44335 has nothing to do with this issue.

@benshi001
Copy link
Member Author

"MOVW $0xffffffaa, R0" is assembled to "MVN $0x55, R0", and MVN can also take a .S suffix.

@benshi001
Copy link
Member Author

But I do not find MOVW.S is really used, shall we disable .S for all "MOVW, MOVH, MOVB"?

@cherrymui
Copy link
Member

"MOVW $0xffffffaa, R0" is assembled to "MVN $0x55, R0", and MVN can also take a .S suffix.

The assembler chooses different hardware instructions to materialize constant, which might change (e.g. for better optimization). Sometimes it doesn't take .S bit. The semantic of .S shouldn't depend on the value of the constant.

@cherrymui
Copy link
Member

MOVW has several variants. It is tricky which forms accept .S bit. Punt to Go 1.10.

@cherrymui cherrymui added this to the Go1.10 milestone May 31, 2017
@benshi001
Copy link
Member Author

We have two ways:

  1. Check .SWP by optab index instead of by instruction, and warn invalid .S for MOVW
  2. Create a new MOVWS along with MOVW

Any better solutions?

@benshi001
Copy link
Member Author

This bug can also be assigned to me.

@odeke-em
Copy link
Member

odeke-em commented Jun 3, 2017

@benshi001 done ;)

@cherrymui
Copy link
Member

I don't think it is necessary to change the existing checking mechanism. It can be checked at corresponding cases of MOVW in asmout.

I don't think creating a new instruction is a good idea. It is not compatible with existing code.

@benshi001
Copy link
Member Author

"It can be checked at corresponding cases of MOVW in asmout."

If so, we need not wait to go1.10, it can be done soon in each case of optab.

@cherrymui
Copy link
Member

It is not where to make the check. The question is among the many variations of MOVW, which should accept the .S bit. For example, I don't think the MVN case you mentioned above should.

This is not a critical bug, nor a regression. Let's wait for Go 1.10.

@benshi001
Copy link
Member Author

Now in "func checkBits", the PWS suffixes are checked via (instruction, bit flags), how about change to (Optab.type_, bit flags). For example,

Case 1 MOVW accepts .S, but case 12 does not. So the
var mayHaveSuffix = map[obj.As]uint8{
AMOVW: T_SBIT | T_WBIT | T_PBIT,
...
} is changed to
var mayHaveSuffix = map[int8]uint8{
1: T_SBIT | T_WBIT | T_PBIT,
12: T_WBIT | T_PBIT,
...
}

@benshi001
Copy link
Member Author

MOVW.P	FPSR, R9   is also silently accepted.

@gopherbot
Copy link

Change https://golang.org/cl/70910 mentions this issue: cmd/internal/obj/arm: better solution of .S/.P/.U/.W suffix check

@golang golang locked and limited conversation to collaborators Oct 17, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants