[LLVMdev] Instructions with overlapping encodings that are disambiguated by field comparisons
Daniel Sanders
Daniel.Sanders at imgtec.com
Tue May 13 07:28:42 PDT 2014
Thanks. I found a few examples there that are fairly similar to my problem. It looks like I'll also need to put one of them in a separate DecoderNamespace to silence the decoding conflict warning. Otherwise tablegen discards both instructions and the tablegen-erated code never calls the custom decoder method.
From: Mihail Popa [mailto:mihail.popa at gmail.com]
Sent: 13 May 2014 14:39
To: Daniel Sanders
Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu)
Subject: Re: [LLVMdev] Instructions with overlapping encodings that are disambiguated by field comparisons
Hi Daniel.
Unfortunately this requires a custom decoder method.
Take a look at the ARM back-end. There are plenty such examples.
Mihai
On 13 May 2014 12:47, Daniel Sanders <Daniel.Sanders at imgtec.com<mailto:Daniel.Sanders at imgtec.com>> wrote:
Hi,
I'm not sure how to handle some of the trickier instruction encodings in MIPS64r6. My problem is that some instructions determine the operation based on the relationship between two fields. For example, 'beqc $rs, $rt, offset' (branch if equal, no delay slot) and bovc (branch if addition would overflow, no delay slot) share the same major opcode and field layout. When the register number $rs is less than the register number $rt, it is a beqc instruction. When the register number $rs is greater or equal to the register number $rt, it is a bovc.
Unsurprisingly, defining both of these instructions in tablegen causes decoding conflicts. Are there any targets with similar encoding/decoding issues that I could look at?
Daniel Sanders
Leading Software Design Engineer, MIPS Processor IP
Imagination Technologies Limited
www.imgtec.com<http://www.imgtec.com/>
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140513/12933737/attachment.html>
More information about the llvm-dev
mailing list