Hi Wilco, On Fri, May 31, 2024 at 6:38 PM Wilco Dijkstra <wilco.dijks...@arm.com> wrote:
> Hi Richard, > > > I think this should be in a push_options/pop_options block, as for other > > intrinsics that require certain features. > > But then the intrinsic would always be defined, which is contrary to what > the > ACLE spec demands - it would not give a compilation error at the callsite > but give assembler errors (potentially in different functions after > inlining). > > What was the reason for using an inline asm rather than a builtin? > > Feels a bit old school. :) Using a builtin should mean that the > > RTL optimisers see the extent of the write. > > Given this intrinsic will be used very rarely, if ever, it does not make > sense > to provide anything more than the basic functionality. > I agree that it's unlikely to get much use. IMO we should be moving the arm_acle.h header to be implemented in the #pragma GCC aarch64 "arm_acle.h" at the top as much as possible. So I'd expect handle_arm_acle_h to be extended to inject these definitions when appropriate and during expansion it'd just generate the RTL pattern for it, which needn't be exposed as an implementation-defined builtin. Thanks, Kyrill Cheers, > Wilco
