[PATCH v2] X86: disambiguate unqualified btr, bts

[James Molloy]

Wouldn't this be a viable use of the third disassembler return value
"SoftFail"? The only difference between its use here and how it is used in
the ARM backend is that the Intel manuals explicitly define the behaviour
in the out of range case, but you could easily reappropriate SoftFail for
the x86 architecture to mean "It's defined, but I'm going to warn about it".

On 17 July 2013 16:09, Tim Northover <t.p.northover at gmail.com> wrote:

> >> I think I like that one even less. It means that we can't reassemble
> >> our own disassembly,
> >
> > I've not been following this closely, but can you explain this? It sounds
> > like we're producing instructions with out-of-range immediates in
> > disassembly.
>
> The immediate takes up a full byte in the instruction stream and
> values outside the [0,31] (or whatever) range have well-defined
> semantics. In my book that makes them valid instructions that the
> disassembler ought to have a representation for.
>
> I suppose that condition could be dropped, though: disassemble the
> alternative encodings as if those extra bits weren't there. That would
> be better than just changing the AsmParser, but still not my preferred
> solution. It's rather misleading for a user of the disassembler.
>
> Tim.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130717/1a7b0c4d/attachment.html>