http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52206
Bug #: 52206
Summary: Strange %P in stack_tls_protect_set_<mode> and movabs
patterns
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ubiz...@gmail.com
Target: x86_64
i386.md has
(define_insn "stack_tls_protect_set_<mode>"
[(set (match_operand:P 0 "memory_operand" "=m")
(unspec:P [(match_operand:P 1 "const_int_operand" "i")]
UNSPEC_SP_TLS_SET))
(set (match_scratch:P 2 "=&r") (const_int 0))
(clobber (reg:CC FLAGS_REG))]
""
"mov{<imodesuffix>}\t{%@:%P1, %2|%2, <iptrsize> PTR
%@:%P1}\;mov{<imodesuffix>}\t{%2, %0|%0, %2}\;xor{l}\t%k2, %k2"
[(set_attr "type" "multi")])
Operand 1 is always a constant generated by
operands[1] = GEN_INT (TARGET_THREAD_SSP_OFFSET);
insn = (TARGET_LP64
? gen_stack_tls_protect_set_di
: gen_stack_tls_protect_set_si);
(define_insn "*movabs<mode>_1"
[(set (mem:SWI1248x (match_operand:DI 0 "x86_64_movabs_operand" "i,r"))
(match_operand:SWI1248x 1 "nonmemory_operand" "a,er"))]
"TARGET_64BIT && ix86_check_movabs (insn, 0)"
"@
movabs{<imodesuffix>}\t{%1, %P0|%P0, %1}
mov{<imodesuffix>}\t{%1, %a0|%a0, %1}"
[(set_attr "type" "imov")
(set_attr "modrm" "0,*")
(set_attr "length_address" "8,0")
(set_attr "length_immediate" "0,*")
(set_attr "memory" "store")
(set_attr "mode" "<MODE>")])
(define_insn "*movabs<mode>_2"
[(set (match_operand:SWI1248x 0 "register_operand" "=a,r")
(mem:SWI1248x (match_operand:DI 1 "x86_64_movabs_operand" "i,r")))]
"TARGET_64BIT && ix86_check_movabs (insn, 1)"
"@
movabs{<imodesuffix>}\t{%P1, %0|%0, %P1}
mov{<imodesuffix>}\t{%a1, %0|%0, %a1}"
[(set_attr "type" "imov")
(set_attr "modrm" "0,*")
(set_attr "length_address" "8,0")
(set_attr "length_immediate" "0")
(set_attr "memory" "load")
(set_attr "mode" "<MODE>")])
The P code is only used on symbol for
P -- if PIC, print an @PLT suffix.
Why do we need it on immediate operand?
