This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Restricting arguments to intrinsic functions

On 24/10/14 15:44, Segher Boessenkool wrote:
On Thu, Oct 23, 2014 at 06:52:20PM +0100, Charles Baylis wrote:
( tl;dr: How do I handle intrinsic or builtin functions where there
are restrictions on the arguments which can't be represented in a C
function prototype? Do other ports have this problem, how do they
solve it? Language extension for C++98 to provide static_assert?)

In the builtin expand, you can get the operands' predicates from the
insn_data array entry for the RTL pattern generated for that builtin.
If the predicate is false, do a copy_to_mode_reg; if then the predicate
is still false, assume it had to be some constant and error out.

This works well; I stole the method from the tile* ports.  It may need
tweaks for your port.

I think we already do that in the aarch64 port in aarch64-builtins.c when we expand builtins.

          /* Handle constants only if the predicate allows it.  */
          bool op_const_int_p =
            (CONST_INT_P (arg)
             && (*insn_data[icode].operand[operands_k].predicate)
                (arg, insn_data[icode].operand[operands_k].mode));

But the accuracy of the source position, as Charles says, is lost by the time the expander kicks in. For eg. in this piece of code,

#include "arm_neon.h"

xget_lane(int16x4_t a, int16x4_t b, int c)
  return vqrdmulh_lane_s16 (a, b, 7);

$ aarch64-none-elf-gcc -O3 cr.c  -S

In file included from cr.c:2:0:
/work/dev/arm/bin/install/lib/gcc/aarch64-none-elf/5.0.0/include/arm_neon.h: In function 'xget_lane': /work/dev/arm/bin/install/lib/gcc/aarch64-none-elf/5.0.0/include/arm_neon.h:19572:11: error: lane out of range
   return  __builtin_aarch64_sqrdmulh_lanev4hi (__a, __b, __c);

The diagnostic issued points to the line in arm_neon.h, but we expect this to point to the line in cr.c. I suspect we need something closer to the front-end?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]