On Tue, Nov 5, 2024 at 6:16 PM Lewis Hyatt wrote:
>
> On Tue, Nov 05, 2024 at 10:56:30AM +0100, Jakub Jelinek wrote:
> > On Tue, Nov 05, 2024 at 10:42:10AM +0100, Richard Biener wrote:
> > > > Actually, I think cpp_token isn't that big deal, that should be
> > > > short-lived
> > > > unless using
On 11/5/24 3:59 AM, Jakub Jelinek wrote:
On Tue, Nov 05, 2024 at 09:32:23AM +0100, Richard Biener wrote:
I think there's the possibility to get back the memory on the GIMPLE
side but I wouldn't make
this a requirement for this patch.
Sure. I'll I'm saying is that we should make some effort to
On Tue, Nov 05, 2024 at 10:42:10AM +0100, Richard Biener wrote:
> > Actually, I think cpp_token isn't that big deal, that should be short-lived
> > unless using huge macros.
> > cp_token in the C++ FE is more important, the FE uses a vector of those
> > and there is one cp_token per token read from
On Tue, Nov 5, 2024 at 9:59 AM Jakub Jelinek wrote:
>
> On Tue, Nov 05, 2024 at 09:32:23AM +0100, Richard Biener wrote:
> > I think there's the possibility to get back the memory on the GIMPLE
> > side but I wouldn't make
> > this a requirement for this patch.
>
> Sure. I'll I'm saying is that we
On Tue, Nov 05, 2024 at 09:32:23AM +0100, Richard Biener wrote:
> I think there's the possibility to get back the memory on the GIMPLE
> side but I wouldn't make
> this a requirement for this patch.
Sure. I'll I'm saying is that we should make some effort to avoid the
growth, not just even withou
On Mon, Nov 4, 2024 at 11:19 PM Jakub Jelinek wrote:
>
> On Mon, Nov 04, 2024 at 10:58:14AM +0100, Richard Biener wrote:
> > > Regarding memory usage implications of this change. It does make a lot of
> > > data structures larger. Here is what it does on x86-64. The base sizes of
> > > some
> > >
On Mon, Nov 04, 2024 at 10:58:14AM +0100, Richard Biener wrote:
> > Regarding memory usage implications of this change. It does make a lot of
> > data structures larger. Here is what it does on x86-64. The base sizes of
> > some
> > types change as follows:
> >
> > location_t: From 4
On 11/4/24 2:58 AM, Richard Biener wrote:
All GENERIC decls (tree_decl_minimal) will grow by 8 bytes (and we have 4 bytes
unused padding). On the GIMPLE side it's probably a "hooray - more space for
flags!". It does feel a bit backwards because the savings we got by making
the TREE_BLOCK p
On Sun, Nov 3, 2024 at 11:23 PM Lewis Hyatt wrote:
>
> Hello-
>
> There is no shortage of PRs complaining about things that go wrong when the
> line_maps data structure in libcpp starts to run into its limits. Being
> restricted to a 32-bit location_t to cover all source locations means it has
> t
On Sun, Nov 03, 2024 at 05:22:05PM -0500, Lewis Hyatt wrote:
> Hello-
>
> There is no shortage of PRs complaining about things that go wrong when the
> line_maps data structure in libcpp starts to run into its limits. Being
> restricted to a 32-bit location_t to cover all source locations means it
Hello-
There is no shortage of PRs complaining about things that go wrong when the
line_maps data structure in libcpp starts to run into its limits. Being
restricted to a 32-bit location_t to cover all source locations means it has
the following limitations, among others:
-Column numbers larg
11 matches
Mail list logo
