b;
a.a=0;
b.a=1;
return f((B*)&a, (B*)&b);
}
is undefined behaviour, even if (in the current implementation of operator==)
it nevers read out of bounds.
From: Jakub Jelinek
Sent: 07 August 2025 18:32:11
To: Thomas de Bock
Cc: Richard Biener; gcc@g
On Thu, Aug 07, 2025 at 03:25:45PM +, Thomas de Bock wrote:
> "I see what you mean, I think there is probably no way to apply the
> optimization to all functions then indeed, since there is no way to
> know if the early break on inequality of a field was arbitrary
> or because it indicates the
rough different means) eventual vectorization of
comparisons. Even if it's through a flag or attribute etc, when
properly implemented this would speed up default comparisons
and decrease code size:
(https://docs.google.com/document/d/1CKp8cIfURXbPLSap0jFio7LW4suzR10u5gX4RBV0k7c/edit?tab=t.0#hea
On Thu, Aug 7, 2025 at 7:18 AM Florian Weimer via Gcc wrote:
>
> * Thomas de Bock via Gcc:
>
> > Sorry for my wording, that is not the only thing memcmp gives us, but it
> > does not give us information regarding which fields mismatched. So we cannot
> > deal with (after !='s are converted to =='s
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]
> :
> _3 = this_13
* Thomas de Bock via Gcc:
> Sorry for my wording, that is not the only thing memcmp gives us, but it
> does not give us information regarding which fields mismatched. So we cannot
> deal with (after !='s are converted to =='s) blocks where not all blocks in
> a chain have the same node as their (e
tfields, for ==/!= all that matters is that
> all bits are compared and the block starts and ends at a byte boundary.
> For <=> it needs the right ordering and for non-unsigned char accesses
> little endian.
Oh interesting I haven't encountered them being swapped yet so I didn't
really conside
On Wed, Aug 06, 2025 at 01:32:07PM +, Thomas de Bock wrote:
> 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 fi
d & e & f & g & h cases, but
> expansion of the && on some targets is e.g. one expression per bb or two
> expressions per bb.
> I'd really suggest you look through what that code does because this
> pattern recognition is similar (but not the same).
> Also note that even in the PHI case
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 conditions to ==
operator== still contains a
> > > > call to B::operator==, making it hard to merge the comparisons of B
> > > > together with those of A. What is weird to me is that even after
> > > > einline and IPA inline passes it seems it is still there as a call,
> &g
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 more like
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 more like strlen).
>
> For straight-line code there's also a bugreport a
On Tue, Aug 5, 2025 at 7:20 PM Thomas de Bock via Gcc wrote:
>
> 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).
>
> Thi
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
15 matches
Mail list logo
