Re: [committed] Fix crash accessing builtins in sanitizer.def and after (PR jit/82174)

[David Malcolm <dmalcolm@redhat.com>]

On Sun, 2017-09-17 at 22:05 +1200, Michael Cree wrote:
> On Thu, Sep 14, 2017 at 04:09:34PM -0400, David Malcolm wrote:
> > Calls to gcc_jit_context_get_builtin_function that accessed
> > builtins
> > in sanitizer.def and after (or failed to match any builtin) led to
> > a crash accessing a NULL builtin name.
> 
>   [snip]
> > This patch updates jit-builtins.c to cope with such entries, fixing
> > the
> > crash.
> 
> Thanks for fixing that.
> 
> I would now like to get access to the architecture specific builtins.
> Any possibility of that being implemented into libgccjit?  My project
> is basically dead in the water without them.

I looked at doing that, but it's a little tricky:

<implementation-notes>

In the C and C++ frontends, the target-specific builtins are registered
by TARGET_INIT_BUILTINS, which is called as:

   targetm.init_builtins ();

early on.

On x86 and x86_64 this hook is implemented by ix86_init_builtins, which
does a lot of manipulation using gcc's "tree" type.

Currently in the jit, the name lookup of a builtin happens as the jit
context is being populated, which is much earlier than when
jit_langhook_init is called (when e.g. we could call
targetm.init_builtins (); ) i.e. it's happening way before trees etc
exist

How to fix this? 

Perhaps the jit could keep the string for the builtin, and defer
looking it up (and checking it) to after trees exist: defer checking to
immediately after the tree init happens.  We could then issue early
failure and bail out during the "compile" of the jit context for
builtins that are still unrecognized.

One thing I don't like about this solution (apart from the complexity)
is that it delays error-checking, and it's best to do emit error
messages as early as possible.   Given that the target-specific
builtins seem to all be prefixed with double underscores (e.g.
"__builtin_ia32_aesdec128"), perhaps we could delay the lookup for
builtins that start with double underscores (not all are target-
specific though).  Or maybe just delay it for everything?  Or add a
different entrypoint for accessing such builtins?

</implementation-notes>

> Secondly, I am trying to work out how to initialise a vector rvalue
> with specified values.  Something in the vein of
> gcc_jit_new_rvalue_from_int() but creating a type with vector
> attribute and where each individual element is set to some specified
> value and it may not be the same value for each element.

I've implemented:

extern gcc_jit_rvalue *
gcc_jit_context_new_rvalue_from_vector (gcc_jit_context *ctxt,
                                        gcc_jit_location *loc,
                                        gcc_jit_type *vec_type,
                                        size_t num_elements,
                                        gcc_jit_rvalue **elements);

which is analogous to:

  { element0, element1, ... elementN-1}

in the C frontend.

> The gcc C manual says "vectors can be subscripted as if the vector
> were an array [...]" so I tried initialising a vector with
> gcc_jit_context_new_array_access() but that fails with errors that
> the vector is not a pointer or array at the time of JIT compilation.

I haven't implemented that yet; do you need it?

Thanks
Dave