Re: __builtin_constant_p and inline assembly constraints

[Simon Kagstrom <simon dot kagstrom at bth dot se>]

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