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
Macro expansion fails with "expected absolute expression" #41170
Comments
assigned to @jyknight |
This will reproduce without a macro and on any target The .if directive is using parseAbsoluteExpression(). What needs to be worked out is whether (. - jumptable) != 0 is not considered absolute. Given that jumptable is before the directive I think that this can evaluate to an absolute constant. |
Is there an easy way to convince MC that this is an absolute expression? |
Not that I know of sorry. The only thing I could think to try was: Looking at the MCExpr code I think that this is because the code for .if uses evaluateAsAbsolute(Expr); There are alternative forms of evaluate that include MCAsmLayout which I think MCExpr needs to know that . - jumptable is a constant. |
It's just that the parser doesn't have access to the MCAsmLayout object and I'm not sure how to pass it to the parser. |
I see what you mean. Now that I think about it I don't think that there is going to be an easy way of solving this in MC. The largest problem with .if is that it can affect the layout itself, for example: label: if the condition passes then a small branch instruction can be used, if it fails then a larger relaxed one might be needed, which might then change the value of condition. I'm thinking that the closest MC is likely to get to being able to evaluate
jumptable: I don't think that this can be accomplished by the existing evaluate expression code though. |
Different from a similar issue llvm/llvm-bugzilla-archive#43759 , which is caused by .if comparing two symbols in consecutive fragments, this issue is due to MC parses a .if statement before a real MCDataFragment created. Symbols are created and placed in a MCDummyFragment, and re-associated with a real fragment when created. If a .if statement is the first to parse within a code fragment, then MC will fail to evaluate the difference of their offsets since the symbols are still in the dummy fragment. I tried to solve this problem when symbols are emitted, which however caused regression and the reason was not easy to identify. So eventually I had to fix the issue when the comparison happens, in a similar way to how I fix llvm/llvm-bugzilla-archive#43759 at https://reviews.llvm.org/D69411. Feel free to suggest a better fix. Thanks. |
jyknight has also authored https://reviews.llvm.org/D70062 referencing this issue. |
Yes this is a better solution, I have removed the redundant code from my patch. |
Extended Description
This is seen when compiling Linux with the integrated assembler. It was first seen in AArch64, but isn't specific to that platform.
$ cat bad.s
.macro jump_slot jumptable, index, label
.if (. - \jumptable) != 4 * (\index)
.error "Jump slot index mismatch"
.endif
b \label
.endm
.text
jumptable:
jump_slot jumptable, 0, realtime
$ clang -cc1as -triple aarch64-grtev4-linux-gnu -target-cpu generic -target-feature +neon -mrelocation-model static -o /dev/null bad.s
:1:5: error: expected absolute expression
.if (. - jumptable) != 4 * (0)
^
bad.s:10:3: note: while in macro instantiation
jump_slot jumptable, 0, realtime
^
:2:1: error: Jump slot index mismatch
.error "Jump slot index mismatch"
^
bad.s:10:3: note: while in macro instantiation
jump_slot jumptable, 0, realtime
^
The text was updated successfully, but these errors were encountered: