[PATCH] Make hint ranges consistent (Was: For the 16-bit unallocated NOP hints, make disassembly representation consistent with their 32-bit counterparts)
Artyom.Skrobov at arm.com
Fri Oct 18 10:17:58 PDT 2013
Yes; the attached patch includes both the tests for the hint ranges, and the
necessary tweaks (in TableGen files and in ARMAsmParser) to make these
consistent, as described in my previous message.
Could someone please review these?
From: Richard Barton
Sent: 18 October 2013 15:45
To: Artyom Skrobov; llvm-commits at cs.uiuc.edu
Subject: RE: [PATCH] For the 16-bit unallocated NOP hints, make disassembly
representation consistent with their 32-bit counterparts
I have applied your refactored patches as 192972 and 192977.
So it sounds like the NOP hints are broken in their ARM and wide Thumb
encodings. Do you plan to supply a patch to fix the issues that you
> -----Original Message-----
> From: Artyom Skrobov
> Sent: 18 October 2013 13:10
> To: Richard Barton; llvm-commits at cs.uiuc.edu
> Subject: RE: [PATCH] For the 16-bit unallocated NOP hints, make
> representation consistent with their 32-bit counterparts
> 1) Attaching the patch split in two, so that someone having the necessary
> permissions could commit it
> 2) There are several issues about the range of hints to be supported in
> First of all, given that the tests for out-of-range hints don't exist in
> Thumb2 nor in ARM (in fact, Joey's r191744 explicitly deleted such
> arguable whether they should go in as part of the "fairly simple change to
> Thumb1 in-line with Thumb2 and ARM support for hints". If necessary, they
> be added in a separate commit.
> A more important point is that the range of supported hints seems too
> defined. Currently, ARM MC supports HINT #0..#255, out of which the last
> overlap with DBG #0..#15 (distinct MCInsts having identical encodings,
> isn't great). At the same time, Thumb2 MC supports only HINT #0..#7 as
> encodings; the range corresponding to HINT #8..#239 is treated as
> when disassembling, and HINT #8..#255, although accepted by the assembler,
> are wrapped-around to #0..#7 (distinct MCInsts having identical encodings
> again). I guess this needs some fixing, e.g. by defining the valid range
> #0..#239, so we can have a consistent one-to-one correspondence between
> MCInsts and encodings. Then we can add
> (back) some meaningful tests for this range.
> As far as 16-bit hints are concerned, the range encodable in a narrow
> #0..#15, so if we want HINT #16 onwards to assemble in Thumb to the wide
> t2HINT, rather than to produce an error, it would require even more
> with the implementation.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 8323 bytes
Desc: not available
More information about the llvm-commits