[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Disabling memmove optimization

From: Michael Matz
Subject: Re: [Tinycc-devel] Disabling memmove optimization
Date: Tue, 26 Apr 2022 17:49:06 +0200 (CEST)
User-agent: Alpine 2.21 (LSU 202 2017-01-01)


On Tue, 26 Apr 2022, Raul Hernandez wrote:

I guess TCC does this as either an optimization (to take advantage of
vectorization in the implementation of memmove), or as a way of simplifying
the generated code.

The latter, plus simplifying the generat_ing_ code (i.e. TCC itself).

My question is: is there any way of disabling this behavior?

Nope. An alternative way of moving arbitrary memory (which a struct copy is) simply isn't implemented in TCC. To solve the problem that would need to happen, i.e. open-coding the memmove/memcpy, with the appropriate care for alignment and target specifics.

Ideally I’d wish to be able to disable it for a single function, but I’d be happy with a compiler flag when invoking TCC or a compile-time define when building it.


This probably sounds like the XY problem; the reason why I need to change that behavior is that I’m trying to write a closure implementation for the V programming language. It works similarly to the approach described in https://nullprogram.com/blog/2017/01/08/, but I’m trying to write it in pure C for portability (so that it works with any calling convention and number of parameters). The implementation works correctly when compiled with GCC and clang, but sometimes fails under TCC because of the optimization I described. Any function calls within the closure wrapper will become invalid after the wrapper is copied somewhere else in memory, since the relative offset to that function will be different and the CPU will jump to a garbage location instead.

If you have control over the closure wrapper you could perhaps avoid the memmove by open-coding any struct copy yourself (with a char-by-char copy loop). If the memcpy/memmove is part of the call sequence (i.e. for struct params or returns) and you control even more of your closure implementation then you can arrange for the problematic types (e.g. all structs) to be passed and returned by reference/pointer and so avoid the problem. If you can't do that, then you'd need to implement the open-code sequence emission in TCC.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]