4
To: Thomas de Bock
Cc: gcc@gcc.gnu.org
Subject: [ext] Re: Addition of compiler flag for dynamic_cast optimization
On Mon, 14 Jul 2025 at 14:57, Thomas de Bock via Gcc wrote:
>
> Hello all, I've been looking into a compiler optimization implemented by
> clang but not gcc that substi
Hello, I'm looking to contribute to the project, hoping to implement the
compiler optimization specified in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164. Would appreciate any
help/tips regarding what files I should look at to start working towards
implementing something like this, cheers
Bock via Gcc
Sent: 06 July 2025 16:46:16
To: gcc@gcc.gnu.org
Subject: [ext] building generic tree to compare base classes at runtime
Hello, currently working on a tiny experimental compiler optimization in the
C++ frontend. Trying to compare the base classes of 2 types at runtime, then if
they
mean I now know I cannot compare the type info in this way, but are there any
already implemented functions that let you retrieve the vtable and the address
of the base class vtable from a type that someone could point me to?
From: Thomas de Bock
Sent: 04 July 20
Currently working with the C++-frontend, I am trying to compare the addresses
of the "trgt" (originally a type) and "src" (originally a class instance)
vtables.
Currently I am successfully retrieving the vptr value of the src instance at
runtime, and the vtable address of the trgt at compiletim
Managed to get it working with:
tree index = build_int_cst (NULL_TREE,
-2 * TARGET_VTABLE_DATA_ENTRY_DISTANCE);
tree src_vptr = build_address(build_vtbl_ref(src_obj, index));
tree trgt_vtbl_decl = get_vtable_decl(target_type, 0);
tree trgt_vtbl_addr =
Hello, currently working on a tiny experimental compiler optimization in the
C++ frontend. Trying to compare the base classes of 2 types at runtime, then if
they are equal, statically cast the second operand's type to the first and the
tree should return the now-casted ptr of the second operand,
Hello all, I've been looking into a compiler optimization implemented by clang
but not gcc that substitutes a __dynamic_cast call for a simple vtable ptr
comparison in the case that the class being cast to is final.
However this brings issues with it in some cases (specified in thread). I
belie
Subject: [ext] Re: Addition of compiler flag for dynamic_cast optimization
On Mon, Jul 14 2025, Jonathan Wakely via Gcc wrote:
> On Mon, 14 Jul 2025 at 14:57, Thomas de Bock via Gcc wrote:
>>
>> Hello all, I've been looking into a compiler optimization implemented by
>&
I have been working on a GCC optimization pass that merges comparisons of
consecutive memory regions with memcmp calls, which get vectorized later with
O2 (regarding https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108953).
This is already implemented in LLVM
(https://github.com/llvm/llvm-project/b
> On Thu, Aug 07, 2025 at 09:37:24AM +, Thomas de Bock wrote:
> > Why does that it not matter that the destination of all the chain blocks'
> > FALSE edge is the same, if we have:
> > :
> > _1 = this_13(D)->a;
> > _2 = _14(D)->a;
> > if (_1 == _2)
> > goto ; [INV]
> > else
> > goto ; [INV]
> On Wed, Aug 06, 2025 at 12:29:09PM +, Thomas de Bock wrote:
> > I've looked at the pattern LLVM recognizes and there is indeed a lot of
> > different
> > ways we could recognize the chains and generalize the optimization.
> > The way I do the pattern recognition now is by changing the condit
> On Wed, Aug 6, 2025 at 9:40 AM Jakub Jelinek wrote:
> > On Wed, Aug 06, 2025 at 08:48:55AM +0200, Richard Biener via Gcc wrote:
> > > For loops the canonical place to perform such optimization is the loop
> > > distribution pass which already recognizes
> > > memcpy but also strlen (strcmp is mo
> > Apologies if I was unclear or misunderstand, I believe that's exactly what
> > I am
> > doing right now. I change the !='s' to =='s' and switch their true with
> > their false
> > edge, from there we can simply find the equality edge by finding the TRUE
> > edge.
> > If this is an unwelcome
14 matches
Mail list logo
