Strange TLS-related x86_64 pattern (Re: [llvm-commits] [llvm] r107860)

[Ulrich Weigand]

Eric,

a while back you added the following pattern to the X86 target:

// This corresponds to mov foo at tpoff(%rbx), %eax
def : Pat<(load (i64 (X86Wrapper tglobaltlsaddr :$dst))),
          (MOV64rm tglobaltlsaddr :$dst)>;

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100705/103832.html


I've been working on some changes to TableGen to enable it to better handle
pre-inc patterns on PowerPC.  As a side effect, those changes add some
extra tests, and those tests noticed the above pattern as having a problem.

The problem is that the "tglobaltlsaddr:$dst" operand only generates only
single operand at the MI level, but the MOV64rm instruction expects a
"i64mem:$src" complex operand which consists of five separate MI operands.
So in principle there seems to be the potential for this to access
uninitialized operand slots.

On the other hand, I could not create a test case that actually shows this
problem, because I could never get the above pattern to actually trigger in
the first place.  We always hit the actual MOV64rm pattern itself:

def MOV64rm : RI<0x8B, MRMSrcMem, (outs GR64:$dst), (ins i64mem:$src),
                 "mov{q}\t{$src, $dst|$dst, $src}",
                 [(set GR64:$dst, (load addr:$src))], IIC_MOV_MEM>;

since the "addr" complex pattern (implemented via the SelectAddr predicate)
appears to already handle TLS related nodes (via address spaces etc.).


Any thoughts what is going on here?   Is the above pattern actually needed?
If so, does the operand number mismatch need to be fixed, or am I missing
something here?


Bye,
Ulrich