This is the mail archive of the
mailing list for the GCC project.
Re: Restricting arguments to intrinsic functions
- From: Andrew Pinski <pinskia at gmail dot com>
- To: Tejas Belagod <tejas dot belagod at arm dot com>
- Cc: Segher Boessenkool <segher at kernel dot crashing dot org>, Charles Baylis <charles dot baylis at linaro dot org>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 24 Oct 2014 09:05:36 -0700
- Subject: Re: Restricting arguments to intrinsic functions
- Authentication-results: sourceware.org; auth=none
- References: <CADnVucA8f3zHOY_UaFvxNAR-j3D7EDvTPiYpoLEUNJL+8TYZzw at mail dot gmail dot com> <20141024144446 dot GA23124 at gate dot crashing dot org> <544A6C08 dot 4020809 at arm dot com>
On Fri, Oct 24, 2014 at 8:11 AM, Tejas Belagod <firstname.lastname@example.org> wrote:
> 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:
> In function 'xget_lane':
> 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
You need to change arm_neon.h to use the __artificial__ attribute as I
mentioned before. Also please move away from "static inline" since
they cannot be used from templates in C++98/03.