On Thu, 2023-12-07 at 17:26 -0500, Antoni Boucher wrote: > Hi. > This patch fixes getting the size of size_t (bug 112910). > > There's one issue with this patch: like every other feature that > checks > for target-specific stuff, it requires a compilation before actually > fetching the size of the type. > Which means that getting the size before a compilation might be wrong > (and I actually believe is wrong on x86-64). > > I was wondering if we should always implicitely do the first > compilation to gather the correct info: this would fix this issue and > all the others that we have due to that. > I'm not sure what would be the performance implication.
Maybe introduce a new class target_info which contains all the information we might want to find via a compilation, and have the top- level recording::context have a pointer to it, which starts as nullptr, but can be populated on-demand the first time something needs it? > > Another solution that I have been thinking about for a while now > would > be to have another frontend libgccaot (I don't like that name), which > is like libgccjit but removes the JIT part so that we get access to > the > target stuff directly and would remove the need for having a > seperation > between recording and playback as far as I understand. > That's a long-term solution, but I wanted to share the idea now and > gather your thoughts on that. FWIW the initial version of libgccjit didn't have a split between recording and playback; instead the client code had to pass in a callback to call into the various API functions (creating tree nodes). See: https://gcc.gnu.org/legacy-ml/gcc-patches/2013-10/msg00228.html Dave
