GNU bug report logs - #41615
[feature/native-comp] Dump prettier C code.

Previous Next

Package: emacs;

Reported by: Nicolas Bértolo <nicolasbertolo <at> gmail.com>

Date: Sat, 30 May 2020 15:09:01 UTC

Severity: normal

Done: Andrea Corallo <akrl <at> sdf.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: 41615 <at> debbugs.gnu.org
Subject: bug#41615: [feature/native-comp] Dump prettier C code.
Date: Sun, 31 May 2020 12:54:23 -0300
> 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.




This bug report was last modified 5 years and 39 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.