[llvm-commits] [PATCH] Change SMRange to be half-open (exclusive end)

[Chris Lattner]

On Dec 18, 2012, at 1:21 PM, Jordan Rose <jordan_rose at apple.com> wrote:

> 
> On Dec 18, 2012, at 11:06 , Chris Lattner <clattner at apple.com> wrote:
> 
>> 
>> On Dec 17, 2012, at 5:10 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>> 
>>> This patch should handle all of this, but I'm seeing a failure in the X86 disassembly tests. This confuses me because I didn't think the disassembler used SMRange.
>>> 
>>>> /Volumes/Lore/llvm-public/llvm/test/MC/Disassembler/X86/enhanced.txt:5:10: error: expected string not found in input
>>>> # CHECK: [o:movq][w: ][1-r:%gs=r{{[0-9]+}}][1-p::][1-l:8=8][p:,][w: ][0-r:%rcx=r{{[0-9]+}}] <mov> 0:[RCX/{{[0-9]+}}]=0 1:[GS/{{[0-9]+}}]=8
>>>>          ^
>>>> <stdin>:2:1: note: scanning from here
>>>> [o:movq][w: ][1-r:%gs=r64][1-p::][1-l:8=8][1-p:,][w: ][0-r:%rcx=r109] <mov> 0:[RCX/109]=0 1:[GS/64]=8 
>>>> ^
>>> 
>>> I'm usually up on the Clang side (all of this is trying to get a new warning into Clang TableGen, with a fixit), so I'm not sure how to debug this one. Does anyone have any ideas why this test would start failing?
>> 
>> This is exercising the "edis" disassembler functionality, which annotates the disassembly with range information about operands, to allow UI tools to put annotations on the disassembled text.  This was originally implemented for LLDB, but as it turns out, LLDB just removed their last use of EDIS (afaik), so all the edis code in llvm is dead and should now be removed.
> 
> Thanks, Chris. The only difference I see is that [p:,] has become [1-p:,]. Does that just means there is better range information than before, or is there actually a semantic difference? I don't want to silently break something else even if the edis tests will be going away.

I really have no idea.  The pertinent change here is probably in the MC *assembly* parser though.  Edis worked by asmprinting an instruction, then reparsing it to get location info.  The reparsing (thus the asm parser) probably has a wrong range somewhere.  Take a look at lib/Target/X86/AsmParser/X86AsmParser.cpp specifically at the getStartLoc()/getEndLoc(), getLocRange() methods.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121218/66d6cb91/attachment.html>