http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49391
Summary: [arm] sp not accepted as input for alu operation
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ph...@gnu.org
Target: arm-linux
$ cat t.c
#define THREAD_SIZE 8192
static inline struct thread_info *current_thread_info(void)
{
register unsigned long sp asm ("sp");
return (struct thread_info *)(sp & ~(THREAD_SIZE - 1));
}
int f()
{
return (int)current_thread_info();
}
$ arm-linux-gnueabi-gcc -O2 -S t.c
$ cat t.s
.cpu arm10tdmi
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 2
.eabi_attribute 18, 4
.file "t.c"
.text
.align 2
.global f
.type f, %function
f:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r3, sp
bic r0, r3, #8128
bic r0, r0, #63
bx lr
.size f, .-f
.ident "GCC: (GNU) 4.6.0"
.section .note.GNU-stack,"",%progbits
The "mov r3, sp" is redundant since sp could be used directly as the second
operand to BIC. It wasn't immediately obvious to me from the predicates on
arm_andsi3_insn why combine wouldn't be accepting sp as an input operand to
that pattern, but apparently it isn't.
(This particular idiom of calculating from sp is used quite frequently in the
Linux kernel.)
