Simon Kagstrom writes:
> At Wed, 23 Aug 2006 10:08:27 +0100,
> Andrew Haley wrote:
> >
> > Does it work if you make the whole thing a macro?
>
> Yes, then it correctly decides that the argument is a
> constant. Anyway, I can live with this behavior since it only makes
> some possible optimizations fail. However, I have another fun problem
> which I think is caused by my fix to the problem.
>
> My fix looks like this (slightly simplified):
>
> #define __emit_parameter(x) \
> if (__builtin_constant_p(x)) { \
> __asm__ volatile ( \
> ".long 0xfffd0000\n" \
> ".long %0\n" \
> : : "i,!r"(x) ); \
> } \
> else { \
> __asm__ volatile ( \
> ".short 0xfffe\n" \
> ".short %0\n" \
> : : "r"(x) ); \
> }
>
> #define _syscall1(type,name,atype,a) \
> type name(atype a) { \
> register unsigned long __v0 asm("$2"); \
> __asm__ volatile (".set push\n.set noreorder\n"); \
> __emit_parameter(a); \
> __asm__ volatile ( \
> ".short 0xffff\t#" #name "\n\t" \
> ".short %1\n" \
> : "=&r" (__v0) \
> : "i" (__NR_##name) ); \
> __asm__ volatile(".set\tpop\n"); \
> return (type) __v0; \
> }
>
> I've added another macro to create the bitpattern for the
> argument(s). My problem now is that these are no longer in one asm
> statement, and clever GCC then outsmarts me by moving things
> around. This is not necessarily a problem, except I get code like
> this:
Weird. There's not really enough information here. Can you provide
the .s file from the compiler? That would give us more of a clue.
Andrew.
