At Wed, 23 Aug 2006 13:43:06 +0100,
Andrew Haley wrote:
>
> Simon Kagstrom writes:
> > At Wed, 23 Aug 2006 12:51:33 +0100,
> > Andrew Haley wrote:
> > > > But I cannot quite understand where the difference comes from. What I
> > > > would like the original macro to generate is:
> > > >
> > > > .set push
> > > > .set noreorder
> > > > .long 0xfffe0009
> > > > .short 0xffff
> > > > .short 9
> > > > .set pop
> > >
> > > So why not do that, then? In a single asm.
>
> But that __builtin_constant_p problem was because you put the call to
> it in a function, not because of any other issues. Why not put the
> *whole lot* in a macro? There's no need to break it into separate
> functions. Why was the function you had before not something like
>
> #define puts(string)
> ({ \
After having looked at this for a few days, I've decided against the
whole __builtin_constant_p optimization. Using #define's instead of
inlined functions only help in some cases - there are still places
where __builtin_constant_p returns 0 and GCC still emits a
constant. One example is when there are two files a.c and b.c, where:
a.c:
int level0 = {0,1,2,0, ...};
b.c:
...
syscall(level0, ...)
here, __builtin_constant_p will return 0, but GCC will happily emit
the constant address anyway.
I've tried to separate the cases by using different instruction
encodings for constant and non-constant arguments by placing the
immediate value and register values on different places in the
instruction (which would make them easy to separate), i.e.,
asm volatile(
...
".short 0xfffe\n"
".short %1\n"
".long %2\n"
:
: (ir)(__builtin_constant_p(a0) ? a >> 16 : 0 ),
(ir)(__builtin_constant_p(a0) ? a << 16 : a )
);
but this also only helps in theory since GCC will actually emit code
to place a0 in a register also for the constant part.
So I will go with the arguments always in registers and make a shot at
implementing constant propagation for the registers when I translate
to Java bytecode instead, which should help at least partially.
// Simon
