bug#41615: [feature/native-comp] Dump prettier C code.

[Nicolas Bértolo]

> I like this considerably less :)

Ok, let's say goodbye to this patch.

> It introduces quite some complexity and the same advantage in
> debuggability can be achieved with something like the attached 8 line
> patch (untested).

Sounds good, I haven't tested it either.

> Generally speaking I want to try to keep our back-end as simple as we
> manage to.

I initially wrote this patch chasing the reason for slow compile times. I think
that a 10k line C file should be compiled much faster than what gccjit achieves.
I thought that "uncommon" (for C) ways of doing thing were causing gccjit to get
stuck trying to optimize them hard, until it gave up. I thought that filling the
static data using memcpy() and constant strings would help GCC recognize this as
a constant initialization and hopefully just store a completely initialized copy
in memory.

I found that GCC would inline memcpy() and the static initialization would turn
into a very long unrolled loop with SSE instructions. I tested this with -O3
only in gccjit to force maximum optimization. I found this super strange
considering that -ftree-loop-distribute-patterns is enabled at -O3 and it should
recognize the naive_memcpy() function as an implementation of memcpy() and issue
calls to libc's implementation. Instead, it was inlining and unrolling it.

> On the subject of 'emit_static_object' the current situation is not
> ideal.  But rather that working around the workaround I believe the right
> thing to do is to improve GCC with a new entry point and keep the
> current arrangement as a simple fallback.

I agree.

> I've already an half cooked GCC patch to allow for directly injecting
> blobs, this should have more then one advantage.  Hopefully I manage to
> start testing it today, I'm rather curious.

Great to hear.

Nico.