[LLVMdev] Intel asm syntax and variable names
Yatsina, Marina
marina.yatsina at intel.com
Thu Jul 23 01:42:47 PDT 2015
Hi all,
I've encountered an issue with x86 Intel asm syntax when using certain variable names.
If you look at the following example, where I try to do a mov to a memory location named "flags2", llvm- mc works fine:
>cat test_good.s
mov eax, flags2
>llvm-mc.exe -x86-asm-syntax=intel test_good.s -o -
.text
movl flags2, %eax
But if the memory location is named "flags", llvm-mc fails:
>cat test_bad.s
mov eax, flags
>llvm-mc.exe -x86-asm-syntax=intel test_bad.s -o -
test_bad.s:1:1: error: invalid operand for instruction
mov eax, flags
^
.text
After investigation, I saw that the memory location named "flags" was matched to the EFLAGS register in the MatchRegisterName() function in the generated X86GenAsmMatcher.inc.
case 'f': // 1 string to match.
if (memcmp(Name.data()+1, "lags", 4))
break;
return 25; // "flags"
So basically, what I'm seeing with "flags" (which should be a legit variable name) is that the X86AsmParser creates a reference to an implicit register instead of a reference to memory.
There are additional issues here as well - what if we compile to SSE, but use a variable named "ZMM0" which is a register in AVX-512? Should this be allowed?
We probably need some way to mark the registers (using attributes or predicates?) so that we'd know which ones are part of the legal set of registers that can be referenced in the architecture we're compiling too.
Do you think this is a good approach?
Thanks,
Marina
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150723/624757e9/attachment.html>
More information about the llvm-dev
mailing list