Re: Correct byte compiler error/warning positions. The solution!

[Andrea Corallo]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Andrea.
>
> On Thu, Dec 02, 2021 at 20:35:50 +0000, Alan Mackenzie wrote:
>> On Thu, Dec 02, 2021 at 16:31:55 +0000, Andrea Corallo wrote:
>> > Alan Mackenzie <acm@muc.de> writes:
>
>> > Hi Alan,
>
> [ .... ]
>
>> > The modifications needed are all and only going into comp.c.
>
>> OK.
>
>> > The function you have to extend is 'emit_EQ'.  You'll see we have an
>> > emit_* function for each corresponding macro/inline function used, ex:
>> > 'emit_XLI', 'emit_XCONS' etc...
>
>> OK.
>
>> > You'll have to define all the new one needed in order to use them use
>> > them in the new 'emit_EQ'.
>
>> Thanks.  I'm currently going through the tutorial at
>> https://gcc.gnu.org/onlinedocs/jit/intro/tutorial....html, so it may be a
>> day or two before I start asking you questions.  ;-)

Hi Alan,

> For extending emit_EQ, I've got the following embryonic scheme:
>
> 1/- Import the C variable symbols_with_pos_enabled:
>
>  gcc_jit_lvalue *syms_with_pos_enabled =
>                gcc_jit_context_new_global
>                  (comp.ctxt, NULL,
>                   GCC_JIT_GLOBAL_IMPORTED,
>                   gcc_jit_get_type (comp.ctxt, GCC_JIT_TYPE_BOOL),
>                   "symbols_with_pos_enabled");

Yep something like.  PS We already have 'comp.bool_type' to use.

> 2/- Extend emit_EQ with lots of nested gcc_jit_context_new_comparison's
> containing GCC_JIT_BINARY_OP_LOGICAL_OR/ANDs, something like this:
>
>   emit_EQ (gcc_jit_rvalue *x, gcc_jit_rvalue *y)
>   {
>     emit_comment ("EQ");
>
>     return gcc_jit_context_new_comparison (
>              comp.ctxt,
>              NULL,
>              GIT_JIT_BINARY_OP_LOGICAL_OR (
>                gcc_jit_context_new_comparison
>                  (comp.ctxt,
>                   NULL,
>                   GCC_JIT_COMPARISON_EQ,
>                   emit_XLI (x),
>                   emit_XLI (y)),
>                syms_with_pos_enabled
>                  ....
>                  ....
>                ) ;
>   }
>
> 2a/- I think I would need C macros called something like ELN_AND and
> ELN_OR to make this half-way readable.
>
> 3/- Have several fragments of gcc_jit code which could be plugged into
> the above, things representing BARE_SYMBOL_P (x), SYMBOL_WITH_POS_P (x),
> and so on.
>
> Can you let me know what you think of this approach, please?  That is,
> before I put a lot of work into it.  Is it broadly a good way of doing
> the job?

I think it could be a good idea but I believe there's no need to use
macros here, we could have just functions return rvalues no?

I'm not a big fan of C macros and I try not to use them whem possible.

>> I can see already I'll need an emit_BASE_EQ (a renaming of the current
>> emit_EQ), and one or two others.
>
>> Hopefully, we'll get this up and running in a few days, or a week or two
>> at most.
>
> I can't help noticing the lack of anything like SYMBOLP in comp.c.  Is
> this just because nothing needs it?

Correct.

> Or is there some other method in
> operation, like using the inline function in lisp.h somehow, for
> example?

Nope.

Tip, while developing I suggest you to dump the pseudo C code generated
using `native-comp-debug' > 1 to verify it looks the way it is expected.

Best Regards

  Andrea